Re: Bizarre XLinks (was Re: Namespace proposal)

[I've added added www-XML-Linking-comments to the CC: list.
XML-DEVers please drop this from replies unless it seems appropriate]


On Sun, 19 Dec 1999, Simon St.Laurent wrote:

> At 09:54 AM 12/19/99 -0800, Tim Bray wrote:
> >At 08:50 AM 12/19/99 -0500, Simon St.Laurent wrote:
> >>It'll satisfy the bizarre demands of the XLink folk that we use their
> >>namespace on attributes any place we create links in our own documents,
> >
> >What's bizarre? -Tim
> 
> 
> The last draft had a nifty if sort of crusty mechanism for specifying
> XLinks using any attribute names you wanted (see
> http://www.w3.org/TR/1998/WD-xlink-19980303#remapping).  The most recent
> draft lost that mechanism and everything requires the use of xlink:href
> instead of myown:src.
> 

> 
> 
> To me, that's bizarre, excessively demanding, and highly irritating
> behavior.  XLink right now is what I call an 'inconsiderate spec', one
> which requires everything else built on it to look like it, without the
> kind of openness that XML provided in the first place.
> 
> I don't know what anyone else thinks of it, but I've given considerable
> thought to a short proposal rebuilding the remapping mechanism, starting
> with xlink:attributes instead of xml:attributes.  (And yes, I know that
> I'll be changing what that prefix maps to, and not just the @#X! prefix.)

> Simon St.Laurent


I'm not sure I get what you're saying here Simon... Does this mean I
couldn't define inter-document relations with URIs such as
'http://x-sitemap.org/xlink-ns/isPartOf' or ...'subsection' or
'...copyrightStatement' and use make namespace'd use of them as
'SITEMAP:isPartOf' or 'RIGHTS:copyrightStatement' to express the type of
the link? From minimal knowledge of the spec, I thought the use of the
XLink namespace was merely for link _detection_, and that link typing
was what mattered w.r.t. community-defined constructs. 

[Dan revisits XLink draft... finds...]

 http://www.w3.org/TR/xlink
          4.4 Semantic Attributes

        There are two attributes associated with semantics, role and
	title. The role attribute is a generic string used to describe
        the function of the link's content. For example, a poem might
	have a link with a role="essay".

        The title attribute is designed to provide human-readable text
	describing the link. It is very useful for those who have
        text-based applications, whether that be due to a constricted
	device that cannot display the link's content, or if it's being read
        by an application to a visually-impaired user, or if it's
	being used to create a table of links. The title attribute should
	contain a simple, descriptive string.


(example snippet)
<A xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:type="simple"
                       xlink:href="students.xml" xlink:role="student list"
                       xlink:title="Student List" xlink:show="new" xlink:actuate="user">
                       Current List of Students
               </A>


Oh. That's kindof retro. Free text? From my re-reading of the spec, it
looks as if the only way to use community-defined constructs is through
the 'role' and 'title' facilities above, which are both free
text. Althought these _could_ contain URIs or (perhaps controversially?) 
namespace-prefixed names, the spec doesn't appear to provide any
mechanism for making such practice syntactically evident. Which is odd,
since my understand of role of XLink was that it was all about
delivering a mechanism which made typed links syntactically evident.


This seems to miss the mark with three of XLink's design goals, and
therefore constitute something of a bug (hence the CC to the WG):

In terms of the XLink goals:

	8. XLink must represent the abstract structure and 
	significance of links. 

Unless a processor can tell when it encountered a URI reference in the
'role', or a namespace qualified name, or free text, Web automation
is going to be severely hampered. If I link to a copyright statement, or a
contents page, or a subsection, or a critique, I want to be able to give
a Web name (URI) to that type of link so that the significance of what
I've done is mechanically evident. The string "student list" doesn't do
this. Trivial example, "student:list" could be free text, a qualified
name, or some new URI scheme. (another eg. news:foo looks like like a
qname and/or a URI).

	9.XLink must be feasible to implement regardless of the 
	media used for the presentation of links. 

Unless a URI for the role/type of a link is evident, user agents will be
incapable of making adequately informed decisions regarding
presentation. Example: 'copyrightInfo', 'healthWarning',
'legalDisclaimer', 'critique' etc are inter-document relations that
might be presented differently depending on presentation media. If these
are represented in free text, they won't be easily recognised.

	10.XLink must be informed by knowledge of established hypermedia 
	systems and standards. 

It might be argued that the significance of unique identifiers in
distributed, multilingual information environments is pretty widely
appreciated these days...


Here's a quick counter-proposal (spot the difference) for 'role':

(amended example from above)
<A xmlns:xlink="http://www.w3.org/XML/XLink/0.9" xlink:type="simple"
		xlink:href="students.xml" 
	 	xlink:role_webID="http://edustuff.org/xlns/studentList"
                       xlink:title="Student List" xlink:show="new" xlink:actuate="user">
                       Current List of Students
               </A>

...so at http://edustuff.org or elsewhere we might find (but XLink
needed specifify in the spec...):

	<LinkRole webID="http://edustuff.org/xmlns/studentList">
	<label xml:lang="en">Student List</label>
	<label xml:lang="fr">List De Students (or whatever...)</label>

	<!-- using URIs would allow additional information/annotations
	 etc, for example... -->
	<generalisationOf webID="http://edustuff.org/xmlns/cleverStudentList"/>
	<sameAs webID="http://someotherlinkvocab.org/education/listOfStudents"/>
	</LinkRole>

I don't want to get into details of alternate mechanisms here, just
wanted to check that I've not misread the spec, and if so, register 
my puzzlement as to the chosen design.

cheers,

Dan

--
daniel.brickley@bristol.ac.uk

Received on Monday, 20 December 1999 07:27:02 UTC