Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: xml:href, xml:rel and xml:type
 Hi Liam, Me again :-). > > > 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. > > But you don't know in advance. The xml:type is just going to > be wrong most of the time. It's advisory. If it's important, it's not going to be wrong. Browsers seem to only care about the @rel="stylesheet" bit, and don't parse @type. So you can leave it out in that case. But if that bit of metadata was used to disambiguate xslt from css requests, for example, it would be more important to the author to get and keep right. That's what it's for: to help drive client state. I will admit that there's not much literature available from google on the use of this attribute. I will do a bit more digging. > > > > 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. > We'll have to agree to differ. Seems that we agree on 2/3 attributes so far ;-). I will keep working on that third one... > > [...] > > 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. > > You have to do that anyway if you want to be complete. > > Suppose you are interested in SVG images. So you don't crawl > to an XML DocBook document. But the illustrations in that > DocBook document were in SVG. So you lose. > > [...] > > > 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. > > When you write the document you don't know what formats the > client will prefer, unless you write for only one piece of software. > > So the document is the wrong place for it. OK, one can produce an image index by crawling html pages and finding linked images; text/html is a rich source of links to image/*. image/svg is a usually a separate media type from text/html, but it is encompassed and overshadowed by text/html when it is produced in-line. If you crawled an xml-based media type, you would likely need the xml:type hint to help you out, in particular where the @xml:rel was not a differentiator, see the discussion of <link rel="stylesheet".../> above. > > > [...] > > > > 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. > > I think that's very subjective - I'd rather add xml:include > and xsi:type myself. But that was why I wrote the > "unobtrusive namespace" stuff, so you could have (in effect) > a predeclared list of namespces. It didn't fly, though. OK, I reflected on this a bit, and I just read the "Automatic Namespaces" paper you gave at Balissage 2009 (sorry!). First, the problem with having links in some arbitrary namespace is that they can be syntactically re-assigned ie. xlink: could just as easily read linkinglanguage:, or an empty string. So links can't be easily recognized. Since xml: can not be reassigned, xml:href always means xml:href, and xml: always has to be present. So links will always be recognised. Automatic namespaces don't change the fact that the href can be in any namespace as defined by the profile in the xml:ns reference document. BTW I think the concept of automatic namespaces is compatible with the concept of a 'profile' link relation, which is being promoted by Erik Wilde over on rest-discuss. http://dret.typepad.com/dretblog/2012/03/resource-profiles.html While Erik's proposal is for a link relation 'profile' which has an associated URI which is abstract (ie. not necessarily dereferenceable), your automatic namespaces xml:ns reference actually associates an xml file describing the profile of an xml file encoded according to a similar concept. xml:ns="http://example.org/myautons.xml" would map nicely to <link xml:rel="profile" xml:href="http://example.org/myautons" xml:type="application/xml;type=autonamespace"/> <link xml:rel="profile" xml:href="http://example.org/myautons" xml:type="application/json;type=autonamespace"/> I think the notion of a profile, and the notion of automatic namespaces both need to consider the MIME media type with a bit more priority. In other words, the concept of a profile and that of automatic namespaces are working in the same space as the role of MIME media type. The MIME media type needs to be known to an application in order to process files of that media type. Just like an application must be built to process UTF-8 characters instead of US-ASCII, an application must be written to process text/html with in-line svg. Whether there are namespace prefixes or not is a programming detail, and one which I as an xslt programmer have been happy to live with. HTML/js programmers, not so much! But the point remains that it is the media type that is the final descriptor of the expected content, regardless of the namespaces involved. And having a link to a profile from within the target document is too late a la either of the above equivalent examples - it needs to be advertised and negotiated prior to pulling in the document, otherwise you get wasted bandwidth etc. See REST. > > > > > 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 > > The kml one is interesting, are you suggesting Google Earth > uses atom in some way? Not very well, IMHO. For example, it does not use atom:link@rel="next", which would be a nice feature for paging data RESTfully. > > The rssboard one is just atom and rss, which is where atom started ;) I guess it came full circle, adding standardized links to RSS. The point is there is a great need for that standardization. > you're in Ottawa I'm only 3½ hours' drive away :-) Well if you're getting the same snow we're getting today, you have my sympathy! 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
|
|||||||||
