- From: Paul Grosso <paul@paulgrosso.name>
- Date: Thu, 17 May 2012 10:55:48 -0500
- To: core <public-xml-core-wg@w3.org>
- Message-ID: <4FB51F84.5040708@paulgrosso.name>
The response to our response: -------- Original Message -------- Subject: RE: xml:rel, xml:href, xml:type Resent-Date: Thu, 17 May 2012 15:50:09 +0000 Resent-From: xml-editor@w3.org Date: Thu, 17 May 2012 15:49:31 +0000 From: Rushforth, Peter <Peter.Rushforth@NRCan-RNCan.gc.ca> To: Paul Grosso <paul@paulgrosso.name> CC: xml-editor@w3.org <xml-editor@w3.org> Hi Paul, Thanks for considering this topic. I would like to add @xml:hreflang and @xml:src to the proposal (see below). > Hypertext linking outside of the document is not something > which needs action at the parser level, so it doesn't need to > be specified in the core XML specification. Well that is disappointing, but not surprising. Can you clarify for me if xml:base is actioned by the parser? It would seem that xml:base manages the location of the current representation/element on the web, so I would have thought the location and nature of referenced resources would also be similarly treated ie not processed by the parser specifically, but passed on to the application at least. I note that the sax parser API appears to use the XML namespace as a constant, http://www.saxproject.org/apidoc/org/xml/sax/helpers/NamespaceSupport.html#XMLNS http://xerces.apache.org/xerces2-j/javadocs/api/org/xml/sax/helpers/NamespaceSupport.html#XMLNS which is more or less the mechanism needed to gain the benefit of the use of the xml namespace, as I see it. So, while the interpreting what is in the xml namespace require xml application support, the transmission of those semantics seems to flow through the parser, like xml:base does, without having specific actions taken by the parser. > The existing XLink Recommendation [1] already defines > namespaced markup for hypertext linking that would appear to > address your requirements. In fact, XLink defines an > xlink:href attribute that appears to parallel your suggested > xml:href attribute. The choice of the xml namespace may seem odd, but it does have the advantage of being syntactically recognizable and immutable, and semantically reserved and seems to be understood or at least ignored by xml processors. > > Note that the xlink:type attribute is not parallel to your > suggested xml:type (and xlink:type is optional and would not > be needed for most uses). Providing the MIME media type of > the link target at the point of the link source is convenient > for some applications but is inherently risky. This risk is built into the architectural style of the web. Given that hypermedia is the engine of application state, the advertisement of alternate representations within the hypermedia served to the client allows the client to choose what media type to ask for. The most efficient network request is a request that is not issued, and to that end, I remain convinced that the "type" attribute (media type) is important enough to manage within response bodies. Yes, the hypermedia can get out of sync with what the server offers if care is not taken. That is understood, and is recognized by the tag finding on the role of media types in web architecture. However, that same tag finding noted the use of "type" in the manner which I suggest: http://www.w3.org/2001/tag/doc/mime-respect-20060412#what : "Type attributes are sometimes used to express expectations about representation types for pre-access content selection." This is the case with html, atom, and although done a little differently, by xinclude (@accept, @accept-language). It's probably important enough to consider including it in xlink, too. The diversity of approaches to hypermedia affordances taken by the specs mentioned above is really the source of my concern. As an example, wall plugs work for everyone with a need for electricity because they share a single form factor. +/- geographical constraint, however the web is not constrained geographically, so we should consider that we're all on the same island together. I'm proposing the development of a single, _immutable_ form factor for xml core hypermedia affordances. Because hyperlinks are so fundamentally important to the way the web works, they should have one, and only one form factor in xml. It might not be the "perfect" form factor, but it should be simple, recognizable, permanent. Oddly, the "no namespace" seems to have similar advantages to the xml namespace (or greater, if you consider visual simplicity), although processors might not be as overlooking of "no namespace" as they seem to be of the xml namespace. All attributes which do not have a namespace prefix are in no namespace, regardless of defaulting. So, if the xml specification (say, or another specification, possibly) was to declare that "no namespace" @rel, @href, @type, @hreflang and @src, (added to the present proposal, below) have one and only one semantic, and regardless of what element they are placed on, it would seem to achieve the same goal. The one major pitfall I see of this approach is that xml application designers who were unaware of the (proposed) normative use of the "no namespace" rule when used by @rel,@href etc, would be at risk of defining incompatible semantics for those attributes when used in their own application. The xml namespace solution does not suffer from that problem, because the semantics of those attributes would be visibly and normatively bound to one definition. XML is not very old. I reckon it will go on for possibly thousands of years. Having one permanent form factor for hyperlinks is vital to enable simple interoperability. Before I close, I would say that in thinking a bit more about links, I neglected to include a couple of link semantics that are important "on the web" and should be considered for inclusion. The first, would be xml:hreflang, and which would advertise the language of the related resource. This is of course a piece of resource metadata which has similar "risks" to those of @type: that it can get out of sync with the actual resource. Still, if the user does not understand the language of the referenced resource, it is reasonable to enable pre-access selection, automatic or not. The second would be xml:src which would signify transclusion of the resource linked to, similar to html:img@src implies that the image file referenced is to be considered embedded within the current representation. That's all, thanks for your attention. Regards, Peter Rushforth
Received on Thursday, 17 May 2012 15:56:24 UTC