RE: [xml-dev] "Introducing MicroXML, Part 1: Explore the basicprinciples

["Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>]

Hi Len and David,

These Socratic dialogues we've had are still on my mind, and I wanted to share a few more thoughts which pull elements from individual emails throughout this thread and earlier ones too.  I think we're not far from the finish/start line, actually.  Hopefully it won`t actually end up looking like a circle, but a path ;-).  I'll try to not stray too far into rhetoric, and I hope you or others listening will correct me if I do.

Before proceeding, I'd like to say that Respect is a lesson I was taught early in my career.  The kind of respect I learned was this: what people have thought about and achieved in the past, especially in programming, is something that should not lightly be tossed overboard.  There are always lessons to be learned from others, by listening and thinking about what is being said.  Recognizing that, sometimes in order to stay afloat, tossing stuff overboard is essential - MicroXML is a rethink and as such it may be necessary to unburden ourselves of a few things.  If there was anyone I would follow into new territory of thinking, it would be James Clark, no disrespect meant to *anyone* on the list.  But, it also may be necessary to provision the ship for the voyage, and that is specifically the piece of the puzzle I want to talk about, and with your help, solve.

"In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state."

> There is a bit of retrofitted history in that description.  The Internet and the web applications as well as others were functional before the term "representational state transfer" was ever coined and that notion was already a part of discussions.

In the light of my respect, I wanted to say that it took me a long time, and a lot of related reading, to fully understand that sentence.   Fielding's writing is excellent, but dense.  The beauty of that writing style is that we have to read and think about each sentence and each paragraph, but it is rewarding - and in thinking about it, we begin to be able to _parse_ and _understand_ it and we're given something new: an idea.  Furthermore, I would say that my understanding of the Ph.D. thing, is that you must describe and defend a bona fide _new_ idea in order to pass.  In the case of Fielding, the idea was not the architecture of the Web, even though it is well described by his dissertation, but the _style_ of that architecture.  Now I don't know how many visual artists there are among us, but I'm pretty sure there are poets here.  And, I bet you they would understand the idea of a poetic style [1].  The Web has a style:  Fielding was the first to identify and describe it.  

[1] http://records.viu.ca/~johnstoi/eng366/lectures/poetry.htm

This is not meant to idolize people, just to try to respectfully understand the ideas of others.  The Web gives us the _tools_ to access the ideas of others almost instantly, if they post them, but does not grant us access to an understanding of them, which takes time and reflection.   And we're not talking about _old bones_ here [2].

[2] http://vimeo.com/4176485

So the phrase you used that you said Charles Goldfarb used, "own the parse", also lit the light bulb for me.  You sometimes hear people use the word "parse" to describe the process of understanding other peoples sentences.  Ie you have to pick something apart before understanding it.  The MicroXML proposal has a lot in common with SGML, I think, especially with respect to namespaces [0].

[0] http://www.sgmlsource.com/infaqs.htm#Namespaces

I think James will help figure out a reasonable approach for the Web, and appropriately apply techniques to help us navigate that.  The key is to have a respectful approach to all that history has taught us.  Otherwise we, the XML community, will end up like Wiley Coyote, forever doomed to repeat our mistakes because we can't learn from what has been achieved.

Back to the Web.  The REST architectural style focuses what is necessary to achieve the "Uniform Interface".  That Uniform Interface is very much like the common electrical receptacle, in my view, except that what it allows us to access is not electricity, but ideas.  But, those ideas are worth more, even.  Now here's the thing.  The architectural style of the Web doesn't just allow us to exchange html-formatted ideas.  It allows us to exchange _copies_ of the raw ideas themselves, expressed as representations.

The representation abstraction is quite important.  We've heretofore exchanged self descriptive messages that have been labelled text/html, for the most part.  People have been putting their ideas in html for a couple or more decades.  But html is being stretched, and I too think it will break, as you were suggesting earlier.  According to REST, it _should_ break into many media types, each identifying the set of concepts that the application needs.  And the one thing in common of *all* of those mime types _should_ be hypermedia affordances. 

Representation _format_ is more important than you think.  In the REST style, every time you add/change an element or an attribute to an XML design, you change the semantics of the message.  XML people would say to that, "Well, duh", I imagine.  Here's something that not everybody knows, however, and I don't know why that is, except perhaps that it takes a lot of reading to connect all the dots:  for the _Web_, you are *required* to register a media type to identify the semantics of that configuration. If you change the configuration of elements and/or attributes, and those changes are not _backwards compatible_, a new media type should be registered.  That is, if you want to exchange its semantics over the Uniform Interface.  Here's what Fielding and Jacobs [3] say about semantics: 

"In Web architecture, communication between agents consists of exchanging messages with predefined syntax and semantics: a shared expectation of how each message's control data and payload (representation data and metadata) will be interpreted by the recipient. ... An Internet media type [RFC2046] is metadata in the form of a short name (e.g., "text/html") that associates the data with a specific format specification and preferred interpretation. The association is formally accomplished through registration of the media type in the IANA media type registry."

[3] http://www.w3.org/2001/tag/doc/mime-respect-20060412

A new mentor told me that the battle here is really about the cost of deployed XML 1.0 code.  I don't see it that way.  Deployed XML 1.0 code should be supported in the REST way: with respect.  That is, if you can't provide simple, backwards-compatible hypermedia to the XML 1.0 agent under the guise of application/xml or whatever the media type, you should bump the media type.  If the client negotiates for the new media type, then it obviously knows about the new semantics.  If it negotiates for the old media type, it may not know about the new semantics, but so long as it is not confused by the presence of new semantics in the message, it is ok to send them.

And Andrew was right, this has been discussed on this list in 2010 by himself, James,  John, and other members of this community,  and also previously by the SVG WG list.  The issue is not limited to the SVG community, it is shared by every single vocabulary that inherits XML semantics (XML media types).  The cost of XML hypermedia?  The time to file the bug, agree on it, add it to the XML namespace "registry" (more below).  The value of a _Hypermedia Web_ of XML with namespaces? Pretty gosh-darn high, if deployed browsers already carry full XML parsers.  I think those html browsers might be willing to recognize XML hypermedia affordances.  Just a guess, really.  The value of a _Hypermedia Web_ of MicroML, with no namespaces, per Andrew, James and John?  Priceless.

So if, as they suggest [3], a media type conveys the shared understanding of how the message will be interpreted, or _parsed_, and that shared understanding is conveyed through a registry, we need a registry for XML stuff.  The XML namespace is already that registry, with a very very high bar to entry.  Perfect.  It should have hypermedia affordances in it, because those support the Uniform Interface: they are the prongs of the plug for the Uniform Interface receptacle.  That way, every new media type that arises, which chooses to, can refer to those public semantics without having to re-invent them, as is being done now.   Cut and paste of non-namespaced elements is enabled.  MicroXML is probably going to be the first media type that will need to, if it is to achieve its goals [4].  In my opinion, the hypermedia affordances requested here [5] are like the gift that a parent gives a child when it goes off on its own in life's voyage: a blessing.  It's not as though the child could not achieve its goals on its own without the blessing of the parent, but it is best for both if that blessing is given.  And, it costs only an infinitely small fraction of its value.

[4] http://www.w3.org/TR/REC-xml/#sec-origin-goals
[5] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17659

In the Web of XML 1.0 - the REST Web - media types will link to media types all with the same shared understanding (support for the Uniform Interface), but conveying different ideas - the content.  This is all possible with existing technology, if we add hypermedia affordances to XML.  In the Next Semantic Web, the one Andrew, James and John are talking about, we will also need the self-same plugs to plug into the receptacles of the REST web.  It may just need a new media type (and suffix?) of its own, because it should be able to pull in semantics from XML, HTML, SVG and ((m)any) others.  Why?  Because (the investment in) all of that Web Infrastructure out there must be respected by whatever comes next - *that* is backwards-compatibility.

> If any browser implementers _are_ considering implementing microxml let them speak up.

That seems reasonable.

So, David, here's my proposal:  Let's have a vote.  I know this is a little irregular, but bear with me, I think it can clarify things.  I notice that James has not entered this discussion.  In fact, I haven't seen him around here since 2010.  Maybe he's waiting for consensus to emerge, or maybe he's just given up.  I hope not, because the future is wide open.

Voting rules: Votes shall be cast in the following order James Clark, Michael Kay, Tim Bray, then everyone else.  If votes are not cast in this order, I do not promise not to raise the xml: hypermedia affordances issue in another thread.  If they are cast in that order, I will respect the result of the vote.  If nobody has voted by Sunday July 1st 2012 at 9 pm Ottawa time, I will take it as a sign that rough consensus is impossible and drop the XML namespace issue. 

There are two proposals here.  You should +1 / -1 both to indicate your support of the respective items.  You can abstain from either vote.

Vote #1:  Andrew Welch, James Clark and John Cowan should lead the development of a W3C MicroXML Recommendation, and be named editors, order to be determined by themselves.

Vote #2: Bugzilla bug #17659 [5] should be accepted by the XML Working Group for due consideration, in light of discussion within and between the XML and Web communities.

Please vote (*in order*).

Warm Regards,
Peter