RE: xml:href, xml:rel and xml:type
Hi Liam, > On Tue, 2012-04-17 at 12:05 +0000, Rushforth, Peter wrote: > [...] > > Web crawlers, to take one example, can't crawl xml, because > there is > > no reliable static markup to identify links in all xml. > > There's also no way to mark what's content, which elements > break phrases, how to make elements bold or italic, which > elements are titles, that Web crawlers need to generate > result snippets. This is because its XML, and html crawlers don't speak an infinite number of media types/vocabularies. The point is, the media type advertisement that is present in @xml:type _tells_ the crawler, or any other client, if they will be able to understand what is at the other end of the @xml:href. One could write an ISO 19115:2003 crawler, for example, and so long as the links were annotated with @xml:type, the crawler could target that media type only, processing the elements in the way it understands them, doing whatever it needs to do to meet its goals (this might not be "search", in the google sense, for example). > > The existence of xml:href solves that problem. > > Unless they are Kreskin crawlers they won't know what to do > with the xml when they find it. > > That is what @xml:type is there for. While application/xml > does not > > tell you too much, there are sub sub media types, media type > > parameters etc to tell you how to process the > representation once you retrieve it. Also, it does not have > to be xml :-). > > Media type tells you what something is, not how to process > it. There are lots of things you can do with an SVG image, > for example, besides simply rendering it. Media type (@xml:type) tells you what the media type of the advertised linked representation might be (not: _is_), so you know if you should be able to process it. An SVG image might be chosen over a png version so the client could edit the vectors, for example. The media type advertisement allows clients to know if they can send an Accept header with a value supporting that use. It's not authoritative, of course, because its metadata in a representation, but it allows for potential efficiencies eg not having to send an OPTIONS to determine media type availability. > Putting media types in static content is generally not a good > architecture. The remote Web server will send a media type as > an HTTP header and that is what should be used - it is > normative, authoritative. > This is why, in HTML, it's <a href="foo"> and not <a href="fo" > type="text/html"> > > Indeed, different HTTP clients (browsers) might receive > different formats, depending on the Accept: HTTP headers they send. For sure, that is what the Accept header is for. But the html author uses the link to his own ends, and it sure isn't constrained to html. For xml, where everyone mints his own media type effectively, @xml:type is essential. > > > > > Why is xml:lang needed for xml itself? or xml:base for that matter? > > Why is linking less important? > > Where you start and stop is fairly arbitrary. We didn't do > xml:id in the first spec either. Exactly. Adding no-namespace-declaration hyperlinks is a big win, IMHO. Take xml:base. That attribute is in the same spirit as xml:href, I think, except it describes *this* document, not *that* document. > > Peter, the people you need to persuade here mostly fall into > two broad camps - (1) people happy with XML and namespaces > and who generally see little or no problem with XLink. XLink > already has the ability to describe the "state of the cilent" > as you call it, to specify link relationships (like the rel > attribute on "a" and "link" in HTML), and does not have the > Web-architecture-breakage of putting media types into links > ;-)... and xml:type isn't putting the media type into the link. It's advertising a representation format available from the URI. Very much link atom:link@type. Why has atom:link grown beyond atom? Because there is no equivalent thing in xml. Nothing against xlink; use it if it fits your needs. The point is all of xml needs links to other documents, and the barrier of xlink is too high. (2) people who have no interest in using XML on > the Web today, and for whom the difference between xlink:href > and xml:href is like saying, buy a Jeep because the rear axle > leaf spring bushings are polyurethane whereas in a Toyota > they're aluminium. > The biggest barrier to XML on the Web today is that when Aunt > Tillie tries it, and leaves quotes of her attribute values, > she gets a really confusing error message. > > The next biggest is lack of architectural forms for search > crawlers and ad servers to use. > > Without ads, and with strict syntax, we're not about to take > over the world. The biggest barrier to use of xml on the web is following web service paradigms which don't use the web architecture to advantage. And, not having hypertext there when you need it. > We are limited in the ways we can change XML itself, although > we can change the layers above more easily. It's the easy part that prevents interoperability on a grand scale. Of course, XML is all about making certain things easy. The other stuff, the really really really important stuff, should come built in and fixed. Cheers, Peter
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format