xml:rel, xml:href, xml:type

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

xml:rel, xml:href, xml:type

Rushforth, Peter-2
Hi,

I think I previously posted this to the wrong list - apologies.


Has it ever been considered to include standardized "typed links" into the core xml specification, in a manner that is similar to xml:base and xml:lang? (ie. via the xml: namespace).

If these attributes were available to xml authors, xml could be a hypertext language without schema designers having to reinvent the markup for this concept; such re-invention  hinders interoperability.

I propose the associated attributes below in the xml namespace

xml:href - a single URI value

xml:rel - one or more space-separated tokens or URIs, which identify the relationships the targeted resource has to the current context.  The value of this element could be defined to be compatible with http linking http://tools.ietf.org/html/rfc5988

xml:type - a single MIME media type, with a value compatible with
http://www.ietf.org/rfc/rfc2046.txt?number=2046


This would allow XML representations the ability to contain "typed links", which is important for RESTful applications.

If this idea is not stupid, how to go about proposing formally?


Cheers,
Peter Rushforth

Reply | Threaded
Open this post in threaded view
|

Re: xml:rel, xml:href, xml:type

Paul Grosso


On 2012-04-06 19:48, Rushforth, Peter wrote:

> Hi,
>
> I think I previously posted this to the wrong list - apologies.
>
>
> Has it ever been considered to include standardized "typed links" into the core xml specification, in a manner that is similar to xml:base and xml:lang? (ie. via the xml: namespace).
>
> If these attributes were available to xml authors, xml could be a hypertext language without schema designers having to reinvent the markup for this concept; such re-invention  hinders interoperability.
>
> I propose the associated attributes below in the xml namespace
>
> xml:href - a single URI value
>
> xml:rel - one or more space-separated tokens or URIs, which identify the relationships the targeted resource has to the current context.  The value of this element could be defined to be compatible with http linking http://tools.ietf.org/html/rfc5988
>
> xml:type - a single MIME media type, with a value compatible with
> http://www.ietf.org/rfc/rfc2046.txt?number=2046
>
>
> This would allow XML representations the ability to contain "typed links", which is important for RESTful applications.
>
> If this idea is not stupid, how to go about proposing formally?
>
>
> Cheers,
> Peter Rushforth
>


Peter,

Thank you for your interest in XML.

The XML specification defines a mostly semantic-agnostic markup
technology that is relatively easy to parse and upon which many
higher level semantics can be built.

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.

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.

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.  The URI points to a resource, and retrieving a
representation of that resource determines the media type.

Also note that the XLink specification allows the definition of
more complex linking relationships, though those extended features
need not be used for simpler links.

paul

Paul Grosso
for the XML Core WG


[1] http://www.w3.org/TR/xlink11/



Reply | Threaded
Open this post in threaded view
|

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

Rushforth, Peter-2
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