[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: xml:href, xml:rel and xml:type
Liam, > > On Thu, 2012-04-19 at 14:37 +0000, Rushforth, Peter wrote: > > 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. > > You can never assume that the result of fetching a resource > will be a particular representation format. You might > actually get anything back at all. For sure you might get > HTML 2 or HTML 4 as part of an HTTP 404 or 401 response, but > content negotiation means you might get image/jpeg instead. > > Instead, it tells the client that the document author > _expected_ a particular type. > > If we can agree that far maybe we can make progress on > understanding each other ;-) @xml:type is embedded metadata, similar in concept the atom:link@type, http://tools.ietf.org/html/rfc4287#section-4.2.7.3 and html:link@type, and is less authoritative than message metadata in http, as described here: http://www.w3.org/2001/tag/doc/mime-respect#media-type My understanding of content negotiation is that the client sends an Accept header with a list of weighted preferences. If the advertisement in the @xml:type does not match one of the client's capabilities, no request to that xml:href URI will ever be made, saving the network bandwidth, and the server the effort of replying to a request it cannot honour. > > I'm personally interested in typed links, where the types are > rhetorical in nature - e.g. "supports", "disagrees", or > express other relationships. This is the relationship of the referenced resource to the current client state, and is supposed to be stored in @xml:rel, which is similar to atom:link@rel or html:link@rel. *I* think you need _both_ @xml:rel and @xml:type to qualify as a typed link. One of the interesting things about @xml:rel and @xml:type is that it constitutes (part of) "media type design", along the lines of what Fielding talked about in his famous rant: "A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types." http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven The domain of design between @xml:rel and @xml:type is a very powerful one. The art of XML document design is well understood by this crowd, (ie. the other part of media type design). I think there are some very important details here that could be improved by @xml:rel, @xml:type and @xml:href, especially because the addition of those attributes enable "hypertext-enabled mark-up for existing standard media types" In reference to Michael Kay's mention of normalization, I see the factoring of meaning between the @xml:rel and @xml:type as a kind of "web normalization". Put the stable meaning of resources in their (dynamic) context (say, an xml shoe :-) into one or more tokens in the @xml:rel (eg. "other"), and the media type hierarchy into the @xml:type (eg. "application/xml;type=shoe) Presto, semantic links. > > > 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). > > Someone else would write a crawler that checked out all the > links and fond the 90% that you'd missed, e.g. when you go to > www.findmylover.com and you get an HTML page that asks for a > country, and then www.findmylover.com/?country=rohan returns > your geographical markup language. > > It's dynamic, not static. Again, the issue about authoritative metadata. However, without the advertisement found in @xml:type, no such crawler is practical, because you would have to crawl _everything_ to determine what is/is not a document you can analyze. Or else you are assuming that everything is one or two media types, all of which you can process. Clearly, that is not the case with xml, beyond simple xml parsing. > > > > > > 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. > > When I wrote Media type I was referring to the label in the > returned HTTP header, which is authoritative. Agreed. But it is not the only place nor role for the media type metadata, as described by the TAG reference above. > > > 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. > > The client can *always* send an Accept header saying they > prefer PNG to SVG. (content negotiation is of course > different from "HTTP OPTIONS") Yes. But again, the advertisement in the metadata is a hint to the client of what to enter into negotiation with. > > > [...] > > > 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. > > Maybe this is where I'm not following your argument. > > Are you suggesting people would register individual > schemas/vocabularies with IANA themselves, or would use types like > application/x-mallard+xml ? No, I think application/xml is top-level. There does need to be some way to continue to specify the document semantics, probably through media type parameters (that seems to be the extensibility mechanism that is provided). If your media type gets important enough that recognition as application/xml is not important, go ahead and register application/x-mallard+xml. IOW application/xml;type=mallard is probably more appropriate for a domain specific vocabulary. Clients who understand type=mallard will quack like a duck, but browsers and other xml-aware but mallard-unaware applications will just display xml syntax coloring, or whatever their default behaviour might be (because they'll ignore ;type=mallard, and request application/xml, if they follow the spec). > > > Exactly. Adding no-namespace-declaration hyperlinks is a > big win, IMHO. > > Is the problem the namespace declaration? There was talk > about that a year or two ago on xml-dev, about reforming > namespaces, but there's too much XML 1.0 inertia to make it easy. Yes, it is one of the problems. But I don't think it is the declaration so much as the fact that users have to declare it and clients have to verify that it matches. The xml:href, xml:rel and xml:type _strings_ can be found without understanding namespaces, I think. Maybe I'm trying to skirt around the issue of namespaces, but I think using the implicit xml namespace is appropriate because web hyperlinking is a top priority use case for xml. > > > 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. > > Hmm, I have not seen atom:link in use outside atom, I'd be > interested to learn more about that and see examples. https://developers.google.com/kml/documentation/kmlreference#atomlink http://www.rssboard.org/rss-profile#namespace-elements-atom-link > > Note that we (W3C) did reduce the barrier of XLink a little, > you only need one attribute now. And declaring an XLink > namespace seems no worse than declaring an atom one to me. I agree that it is no worse, except for the complexity, not to mention controversy (apparently, did not know of that before starting this discussion) around xlink. Again, having a specific domain standard add linking to xml is not the right way to go - it needs to be baked in. And the namespace is also a slight barrier, per above comments. > > [...] > > > 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. > > I wonder if we got 20 people in a room together we could get > agreement on "the biggest barrier"... :-) Maybe not. Not to worry. > > Web services are rapidly moving to JSON. Stop the bleeding! Use REST+XML! > > Sorry for a long reply. NP. Just want to make sure you realize I am not a crank caller. 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
|