RE: xml:rel, xml:href, xml:type

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:50:01 UTC