Re: "Introducing MicroXML, Part 1: Explore the basic principles of MicroXML"
Michael Kay <mike <at> saxonica.com>
2012-07-02 10:25:55 GMT
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 <at> lists.xml.org
> subscribe: xml-dev-subscribe <at> lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>
_______________________________________________________________________
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 <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
I don't think banning é would fly - it's part of MathML and HTML.
It's possible that having the HTML + ISO + MathML entity sets hardwired
into Web browsers and explicitly allowing programs to handle undeclared
entities in such a way would get somewhere.
Liam
RSS Feed