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

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

Liam,

> On Wed, 2012-07-04 at 13:30 +0000, Rushforth, Peter wrote:
> 
> > So, I guess those parsers could also resolve xml:href and xml:src 
> > references, and leave the interpretation of the link typing to be 
> > worked out by the application.
> 
> What would be the use of that? The parser _needs_ to resolve (and
> follow) URIs in system identifiers, so it _needs_ xml:base.

I guess it might be useful so that all of the logic to resolve URIs would not have to
be re-implemented everywhere URI resolution is necessary, the parser
could present the URI as already resolved, via the api that it presents to its client,
per what Henry says in a later email.

The goal however is to
let XML applications succeed, not parsers, so parsers should do what is
necessary to allow the XML application to proceed. 

> 
> The majority of XML systems are not connected to a user interface.

It doesn't matter whether the semantics are presentation markup or 
musical notes, the markup does something by virtue of what they are connected to.  
If links are in the markup,
they mean the application needs to get something or otherwise change
state.  This is REST!  And furthermore, it allows clients to not have
to load huge XML files all at once, they can sip them as required.  
See atom:link@rel="next".

> 
> [Peter quoting David Carlisle:]
> > > Given that a large part of xml _on the web_ is xhtml and 
> that uses 
> > > href rather than xml:href,
> > 
> > I gather you don't often see application/xhtml+xml in the wild?
> 
> Not often, because of Internet Explorer prompting users to 
> save the file instead of displaying the resource, and because 
> that MIME content type header invokes draconian error 
> behaviour in browsers, whose authors decided not to attempt recovery.

If clients want xhtml they can negotiate for it, but I don't agree
with trying to xml-ize html.  A new approach is required there, and James
is someone with the stature and background to make the ends meet, I think.

I hope he gets back soon!

> > > I still don't think you've
> > > provided any use case where an application that 
> understood this new 
> > > xml:href proposal couldn't just as simply understand an href 
> > > attribute.
> > 
> > Of course it could, but libraries can be re-used, so if the 
> > affordances are built into one namespace (xml:), then a 
> library can be 
> > written to provide services to applications across many use cases.
> 
> The libraries have already been written, though, using HTML. 
> Thousands of them.

Isn't that a problem?  Or at least, couldn't the burden be placed elsewhere
so that things would work better?  For example,  when I see a link[@type="application/xslt+xml"][@rel="stylesheet"]/@href,
it would be great if the application actually negotiated for application/xslt+xml among its
Accept: preferences.  But, the application can't negotiate if it is not aware of that 
attribute's value, which it should get from the parser api, per Henry's comment.

> 
> You're right that if we were starting again with XML we might 
> consider xml:href 

Liam, not just xml:href, _all_ the known hypermedia affordances which have
evolved through _extensive_ use in html and atom to date.  And, we _are_ kind of starting again,
because isn't the objective of XML to succeed on the Web?  Not too late!
Just the right time: we've got _experience_.

>(although it would certainly meet with 
> strong opposition because of the software layering violation).

Well, I looked at wikipedia on the subject of layering, and I could
not really make up my mind as to what 'layer' XML is in.

Fielding says that layered system is a "pure" style, but that its
use in network-based systems is limited to its combination with the
to provide layered-client-server ie it is a concept that is adapted
for use in the Web, not vice versa. [1]  Maybe we should ask Roy for his view 
on that?

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_4_2

I think that's what "affordances" are: they are like hand-holds for
a mountain climber (the application), allowing it to traverse the slope
and arrive at its goal.  The more we use them, the better the trail.

So, maybe as when Mike Kay first evaluated the idea of the WWW, he
thought it would never fly, maybe xml:affordances is like that layer thing for
the WWW:  not "pure", but hybrid, and workable.  If parsers make xml:base
available via an api to the application, they could do the same for other
affordances.  The browser seems to be in charge of network access, and perhaps
it is a client of that parser api?  If so, it would need to know what media
type (@xml:type), for example, to negotiate for if a link is selected.  Same
for (@xml:hreflang, @xml:method).

> 
> The goal of the XML work was to put SGML on the Web alongside 
> HTML. 

It's not too late to improve the story.  Just the right time, in fact.

> It was not to replace HTML. If it had been an attempt 
> to replace HTML, as Jeni Tennison pointed out in Prague this 
> year, XML would have looked very different.

Right, XML is XML, HTML is HTML.

Cheers,
Peter