I haven’t really worried much about RDF because it doesn’t buy Windows Live enough for it to matter. XML and JSON support are widespread on our primary target platforms, RDF isn’t. This isn’t about technical supremacy, it’s about business. Right now the business case for RDF doesn’t appear to be there so I don’t worry about it.

As for Feeds (e.g. RSS/ATOM), I tend to see them as result sets. In other words a feed is, to my mind, a bunch of independent documents that have been pulled together using RSS/ATOM as a wrapper. Obviously I’ve been heavily influenced by GDATA.

It will still be necessary to model the feed in the infoset so it can be directly manipulated (which, ironically, is so far the only scenario we have where it would make sense to mark an element’s contents as being ordered – remember, we explicitly don’t support markup) but semantically I see it as a container for data rather than data itself. I know I’m slicing this one pretty damn fine.

As for the text box, I agree, I’ll add that to my infinite ‘to do’ list. :( The top of which is to move to WordPress 2.

I like the idea of the Tag URI scheme. I wasn’t aware of it. Thanks for pointing it out. It certainly would be a better choice than data.

I also think it’s not a big deal to map the DNS names into http names. The infoset name could be “com.microsoft.schemaspace.live.schema” and the HTTP equivalent could be http://schema.live.schemaspace.microsoft.com. We could write a trivial piece of code (probably stolen from our custom domains group) to automatically create domain names in some reserved part of our DNS range (E.g. schemaspace.microsoft.com) that could provide info on the schema and work in XML.

As for comments. My feeling is that comments shouldn’t be in the infoset because they aren’t and shouldn’t be processable. But that does not stop them from being in the serialization! If we serialize to XML then XML can contain a comment and if we serialize to JSON then JSON can contain (albeit slightly illegally) a Javascript comment.

But I think the real thing to keep in mind is that unlike the XML infoset, our infoset is really meant to be theoretically. I have no intention nor desire to ever create something like the XML DOM that attempts to manifest the infoset directly. That’s why I want schemas. Programmers can annotate the schema with information on how they want to read the data in and out of their language of choice.

In any case, I like E4X a lot and if it were widely implemented then I do believe that JSON would lose a lot of its allure. Unfortunately until 80% or so of browsers support E4X we can’t justify supporting it in Windows Live Land. Hence the allure of JSON. You can validate that a JSON structure from a third party is ‘safe’ using regex (which is built into modern Javascript so it’s reasonably fast) and then eval it in order to load it (which is also reasonably fast). The perf boost is just nuts. The bandwidth reduction is also nice.

One question though: if E4X was widely implemented cross-browser, would you even care? You would just stick to using the subset of XML you propose (which is basically the SOAP infoset minus attributes), and wouldn’t ever need something like JSON.

wrt. data:com.microsoft.live.schemas: I think it would be good to have a plan to come up with a URI that uses a properly registered scheme.

The “tag” URI scheme (RFC4151) comes to mind, but it requires to decorate the DNS name with a date
when the URI was issued (this to prevent URIs to become ambiguous when ownership changes). Of course that could be compensated by always using
the data of the Live Infoset spec, for instance tag:com.microsoft.live.schemas,2006.

In general however, I think mapping to http would be better; it provides a
simple way to optionally provide documentation for the element.

Regarding the other simplicifations compared to the XML Infoset: they all
seem to make sense, although I would rethink leaving comments out. One would
need to specify that they don’t have sematics, that’s it. Keep in mind
how useful they can be in debugging issues. If they are left out, people
are likely to use element information items instead (which may be ok if there’s
a mustIgnore extension rule).

Best regards, Julian

My point about attributes was (I hope ;) a tiny bit more subtle than that. Attributes should be reserved for standard use only; they’re a convenience when you need to add things like typing, serialisation details, ordering, etc., but in the hands of end users, are almost always abused. They’re a syntactic honey trap.

Even then I wonder if it’s really good to allow them to intrude into the data model.

Consider the RDF data model (yeah, yeah, I know, insert cynicism about SW here). They came up with this wonderful, beautifully simple data model — just nodes and arcs, baby — and then went and screwed it up by adding warts for datatyping and i18n. Urgh.

Speaking of which, what about profiling RDF? If you constrain it to rooted subgraphs, it’s really intuitive, and maps to most languages well (try playing with sparta). Having explicitly named properties is a good thing.

Finally, how do you see this relating to feeds (RSS and Atom)? Would you try to model the whole feed as this, or treat a feed as a container of infosets? Off the top of my head, the latter seems more interesting, but I’m still thinking about it.

Cheers,

P.S. Make your edit box bigger!