Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
