|
Indeed and we looked at XCAP. The main issue is that our
underlying data model isn’t XML. It’s an infoset that is radically
simpler than XML. This wasn’t an accident. It reflects how data amongst
all of our services are generally stored. So to be meaningfully XCAP compliant we
would have to support features that aren’t meaningful for us like
ordering or attributes. And, of course, we want to have full exposure through
JSON. I could imagine a XCAP to JSON mapping (JCAP?) but I think that trying to
reproduce XML inside of JSON rather defeats the point of using JSON in the
first place. But nevertheless it is possible to think of Web3S in particular as
a sub set of sorts to XCAP. I already have a work item to add an entry to the Web3S FAQ on
XCAP. Julien brought it up before. Yaron From: Lisa Dusseault
[mailto:lisa@xxxxxxxxxxxxxxxxx] On first blush, this sounds extremely like XCAP: http://www.rfc-editor.org/rfc/rfc4825.txt Lisa On Jun 20, 2007, at 5:20 PM, Yaron Goland wrote:
One of the most important aspects of this
structure is how to create URLs from it. A caller would need to know the
structure's root out of band. Let's say that root is http://somewhere.live.com/somerootfeed/.
In that case the root of this data structure would be URL addressable using http://somewhere.live.com/somerootfeed/com.live.livecontacts.LiveContacts.
However anyone with a copy of this structure can reference any part of it at
will. For example, if we wanted to address the PostalCode element inside of
Location the URL would be http://somewhere.live.com/somerootfeed/com.live.livecontacts.LiveContacts/com.live.livecontacts.Contacts/com.live.livecontacts.Contact(69257004-966e-4ee1-8552-5564f17c7cad)/com.live.livecontacts.Locations/com.live.livecontacts.Location(1)/com.live.livecontacts.PostalCode. |