Re: [xml-dev] "Introducing MicroXML, Part 1: Explore the basic principle

[Michael Kay <mike@saxonica.com>]

I'm flattered to be included in the list of the great and the good, but 
I really feel I should decline the honour. I've very often in my career 
been elevated above my level of competence, and the result has always 
been failure. When Tim Berners-Lee first articulated his vision of the 
web, a friend of his father Conway asked me for my opinion, and I said 
it was all wishful thinking, far too ambitious, and would never fly.

And in hindsight I think I was right: the probability of success was 
indeed very low. Perhaps that's true of nearly all the projects that 
have radically changed the world: they all had a very low probability of 
success.

A couple of things do seem clear:

(a) if you want to do something radical, it won't take off in the way 
intended unless the cost/benefit is very favourable and the risk very low

[(a') on the other hand, there's just a chance it may take off in a way 
that wasn't intended, but by definition, you can't plan for that]

(b) the chance of something being successful has very little to do with 
its technical merit; asking software engineers to create a standard that 
will dominate the web in five years time is like asking composers to 
write a song that will win the Eurovision song contest. Inviting the 
best composer won't greatly increase your chance of winning.

(c) one of the reasons new technologies often fail is that the best 
ideas get borrowed and incorporated incrementally into old technologies. 
So if you do something really new and worthwhile, its best features will 
appear next week in CSS and HTML5, and then people will think they don't 
need your new stuff after all.

The world in which most of us are playing (content on the web, XML, 
linking, etc) has two dominating characteristics: it's a technical mess, 
and it's extremely successful. The fact that it's so successful makes it 
very hard to sort out the mess, because if it's not broken then it won't 
be fixed, and people won't accept that it's broken it it appears to work 
(which it does).

On linking, there is a lot to be said for the argument that linking on 
the web only works BECAUSE it is a mess (i.e. it violates all the 
principles that the hyperlinking community previously thought were so 
important.) This seems to suggest that we can only make it better by 
evolution, not by intelligent design. So appointing a group of highly 
intelligent designers might not be the right strategy.

As for Peter's votes, I'll abstain. Whatever I say, I'm more likely to 
be wrong than right.

Michael Kay
Saxonica



On 30/06/2012 09:13, Rushforth, Peter wrote:
> 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
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>