M. David Peterson: WebW3S is Microsoft’s answer to a RESTful web publishing protocol. In many ways it attempts to tackle the same problems solved by the Atom Publishing Protocol.
I took a look at “Web Structured, Schema’d & Searchable”, and found Structure, but was unable to find the Web, Schema, or Search.
But let me first back up.
The web on which the Atom Publishing Protocol concerns itself consists of resources which may be binary (things like GIFs and JPEGs), markup (things like HTML and XHTML), and arbitrary XML; and furthermore may contain outbound links to resources which can reside either on the same host or on different hosts.
The data that Web3S concerns itself with consists of element information items (EIIs) which, in Web3S at least, must always form acyclic single rooted trees. EIIs have a name, an ID, a parent, and zero to many children. EIIs are explained in terms of the XML Infoset, though apparently serializing the Web3S Infoset into/out of JSON is an open issue (3SAFQ), as for that matter so is XPATH (3SAFO) and SEARCH (3SAFP).
While I see little in this document that relates either to Atom or APP, my read is that if Web3S were recast using FOAF and SSE, it would be a home run.
The mapping of a self-contained acyclic self rooted tree onto a portion of URI space is via a “Non-Web3S Prefix Path” which is defined thus:
The part of a HTTP URL path that points to a Web3S root EII. For example, if the root EII com.example.lists is addressable as http://example.com/web3sparser/joesstuff/com.example.lists and com.example.lists is a Web3S resource then web3sparser/joestuff is the non-Web3S prefix path.
A more complete example can be found in Example 3:
So from this, we can conclude that on a host named cumulus.services.live.com, rooted at /firstname.lastname@example.org/LiveContacts is a Web3S acyclic single rooted tree.
Section 3 disclaims any relation of the term “schema” as described by this document has any relationship with any existing schema language in this manner:
the actual representation of the schema (if any) is not constrained by this spec. (Read: No, this has nothing to do with XML Schema.)
That being said, the infoset is sharply constrained:
All elements in the Web3S infoset are named using reverse domain names. So the ‘proper’ name of the root element is com.live.livecontacts.addressbook. To make it easy to serialize into XML we split the name such that the last segment becomes the XML localname and the rest of the DNS name, prefixed with the protocol identifier Web3SBase becomes the namespace.
While search and JSON are planned future enhancements, boxcarring has made it into the spec in the form of a proposed new HTTP verb: UPDATE.
The UPDATE method allows the caller to bundle “three kinds of changes to a resource – create a value that is not there, update a value that is there and delete a value that is there — into a single request.” As near as I can tell, all such requests must be scoped to a single Web3s tree.
This document also describes infoset merging; I can’t help but wonder if SSE fits here. As it stands, Web3S appears to be a single user database; once you accept updates from multiple places the situation becomes a bit more complicated.
There are two new media types (Application/Web3S+xml and Application/Web3SDelta+xml), two new URI Protocols (Web3S and Web3SBase), and one new HTTP method (UPDATE) defined in this document.
I can find no discussion of binary data, in fact everything seems defined in terms of the XML infoset. Given that all data needs to be in a namespace, and that all such namespaces need to use a new URI protocol, one can conclude that no existing XML documents can be directly handled by Web3S.
Web3S data is further constrained to be a self enclosed tree. There is no general concept of a hyperlink in Web3S, neither to external data, nor within a tree. To traverse this data, one needs to be aware of the specific schema employed by the application. Adopting either XLink, or some conventions (e.g., xml:base + href attributes), would make this data crawlable.
The data structures that motivated these requirements seem to have much more to do with FOAF (or perhaps OPML) than Atom or RSS. Both FOAF and OPML are inherently “linky”, distributed, and web like.
Sam Ruby and Tim Bray have read Microsoft’s WebS3 specification and offered their analyses: Sam Ruby : I took a look at “Web Structured, Schema’d & Searchable”, and found Structure, but was unable to find the Web, Schema, or Search. Tim Bray :...
I don’t know if Web3S is a good idea or not (I first heard about it when everyone else did), but it’s certainly not embrace and extend. Embrace and extend would be to build on APP with namespaced, proprietary extensions--which in fact is exactly how APP was designed to work and how GData works. All the APP folks are criticizing Microsoft over this precisely because we DIDN’T embrace and extend APP!
RESTful Live Contacts for Internet-scale social networking
It’s been an interesting couple of weeks for folks who care about RESTful web services. Dare Obasanjo kicked things off with a couple of items about the Atom Publishing Protocol (APP) and Google’s use of it for its GData project. Tim...
Thanks for taking the time to read the spec and provide feedback! Yes, I know, the search and schema are both current missing (it is an alpha after all) but anyone of a certain age might remember WebDAV which was really WebDA for a while before the V finally showed up. Stretch goals are good.
FOAF – I think using the FOAF vocabulary makes a ton of sense. On the other hand requiring RDF is, I believe, too high a barrier to entry. I think we need to work very well using vanilla JSON and XML. But that does not preclude RDF nor does it preclude us using RDF vocabularies like FOAF outside of RDF. I need to think hard about this one because the idea of using FOAF both in our vanilla JSON and XML serializations as well as in a RDF serialization sounds ‘right’.
SSE – I have met with the SSE folks several times over the course of the project. What we agreed was that it made sense to build the SSE meta-data directly into Web3S. So that’s the plan. UPDATE is just dandy for sinking with a single server but you need SSE to handle more sophisticated multi-server scenarios.
Binary – We will probably end up extending the infoset to address binary data. I was trying to avoid this for simplicity reasons but too many reasonable use cases are crossing my desk for me to successfully push back.
Existing XML Documents – Correct, existing XML documents cannot be serialized into/out of Web3S other than as encoded values. This is the price we pay for having a radically simpler infoset than XML’s.
External Links – Actually section 10.1 and 10.2 of the Web3S spec define a standard way to put URLs into a document and to define what those URLs are pointing at. As we combine with Astoria, which has a graph based model, we will probably make this format richer. I’ll be looking to steal ideas from APP and RDF.
Microsoft has recently published the Web3S specification which describes a RESTful protocol for accessing Windows Live Services . I’ve read about it in this Dare Obasanjo 's blog entry . I’ve read this entry and associated Web3S FAQ with interest,...
Update: I’ve added more detailed links and summaries how this could fail in my next blog post . Web3S seems to be clearly be driven by a need for hierarchies; from the discussions ( Dave , Tim , Sam ), examples about books and authors, and the FAQ...
Mike Flasko and Pablo Castro of the Astoria Project team posted URI Format - Part 1 - Addressing resources using URI path segments on September 21, 2007. This post, which was converted from a subitem in the LINQ and Entity Framework Posts for...
Atom and AtomPub Support Extended to Windows Live Photos and Application Based Storage
The David Treadwell on New and Updated Windows Live Platform Services post of February 27, 2008 to the Windows Live Dev News blog includes an “Atom Publishing Protocol (AtomPub) as the future direction” topic. Under it Dave says: Microsoft is...