An XLink telco issues roundup arguing for XLink remapping

After mulling over last week's XLink telephone converence [1], I've
made a summary of issues from the perspective of supporting the option
of remapping link semantics on multiple attributes.  Here it is:

The most important misconception may be that XLink discussion is
between "elementists" and "attributists".  Perhaps the groups are
better described as "elementists" and "choicists", or better:
"element-alwaysists" and "remapping-if-and-when-best-ists".  I sense
that the key division is in whether or not the XLink elements can be
hidden from authors through a simplifying remapping while providing
browsers and bots with the required access to the XLink-defining
element structure.  I am convinced, as are others, that a remapping
meeting these requirements can be created and should be pursued.

Before discussing author-based motivations for remapping, here's a
more direct motivation: legacy.  All of the HTML, SMIL, etc. documents
currently on the Web, and in any event most of those coming up in the
next year to two, have no XLink elements in them.  An element-only
XLink will keep the links in these documents hidden.  A remapped XLink
will make these legacy links First Class XLinks along with all links
made during the upcoming XLink era.  Any approach that does not
include legacy links would have to argue what advantages obtained
outweigh this disadvantage.

However, remapping is desired by authors of upcoming documents as well
as processors of legacy documents.  Authors within a document class
will prefer to author their documents as they see it in the most
efficient way possible.  They will often want to just type href= and
longdesc= and trust that they will always mean what they are meant to
mean.  They will often not want to type two or three levels deep of
element nesting describing the same link meaning every time the make
the same type of link.  When argued in the telco that requiring XLink
elements in author-level instances will make the structure too
complex, a counter-argument was that the authors are smart enough to
handle it.  However, authors' intelligence also enables them to choose
alternatives that better suit their needs.  Just because they are
smart enough to handle complex element structure doesn't mean they'll
want to -- they are smart enough to make their job as simple and
efficient as it can be so they can do more.

There are already alternatives available for applying link semantics
to author-simplified instances, as discussed in the telco.  If W3C
does not provide an XLink remapping, then authors will have plenty of
others to choose from.  The Web will have XLink remapping -- this is
not up to us to decide.  We can, however, decide *how* XLink can be
remapped -- but, of course, the first step is committing to doing so
and getting a group started before other solutions start to dominate.
Those opposed to remapping as "yet another language" should take note
that several competing alternatives of this "yet another language" are
already emerging.  The best we can do is make it only one "yet another
language".

Of course, there are requirements to be met in making such a
remapping.  The concerns mentioned in the telco should be among these
requirements.  I believe all the requirements can be met

The basis of any remapping architecture is that you have format
designers who set up the XLink specification of the linking semantics
in their XML formats, and then you have authors who write documents in
these formats.  First of all, let's make it clear that no one wants to
prohibit authors from putting XLink elements directly in their
instances.  Language designers may be able to prohibit this in given
languages, but we could encourage them not not and inform them of the
benefits of allowing authors, should they want to, to indulge
themselves in the full glory of XLink elements.  I see no reason, for
example, to have XLink elements in HTML that authors can choose to
use, as long as they can alternatively choose to use remapped
attributes instead (and have more than one such remapped attribute per
element).

Another concern was about the availability of the XLink structure, and
the certainty and efficiency of this availability.  CSS is a useful
analogy, though it is not the "style" aspect but the "sheet" aspect
that applies.  XSLT may be a better analogy, since structural
remapping is necessary as well as property/attribute.  (XSLT has been
proposed as a solution as well.)  We discussed how the various levels
of remapping that CSS provides also applies to XLink remapping.  These
are

 - PER LINK (ELEMENT) INSTANCE

   CSS gives a style= attribute.  By analogy, direct XLink element
   structure should be allowed instead of attribute shortcuts in the
   document instance.  I think everyone is already in agreement that at
   least this should exist (since XLink defines at least this as is).

 - FOR A WHOLE DOCUMENT

   CSS code for a whole document can appear in one place within its
   <head>.  By analogy, a document-wide XLink remapping should also be
   allowed in one place directly in the document instance code.  This
   still give the author shortcuts, but keeps the XLink remapping code
   in the document itself.

 - FOR MULTIPLE DOCUMENT INSTANCES

   A CSS file can be referenced by a <link> element from the <head> of
   one or more document instance files.  By analogy, one XLink
   remapping URI could be in multiple document instance files, giving
   the same shortcut constructs in these files the same XLink
   semantics.  I understood that some objected to the uncertainty of
   this-- that they wanted more of a guarantee that the XLink
   information was accessible with the document.  But doesn't the same
   argument apply to CSS?  Some may argue that style is less important
   than linking, but stylists would still want the same guarantee.
   Such file referencing, be it for CSS or XSLT or XLink remapping,
   should be dependable.  It is the obligation of those providing the
   shared resources to keep them universally accessible.  Another
   argument against file referencing is that is slows processing down.
   Authors who want additional certainty of information availability
   or speed can opt to include the (CSS, XSLT, XLink) remapping code
   directly in the document.  I think people should be able to choose
   either way.

 - FOR A WHOLE DOCUMENT CLASS

   CSS, of course, does not provide this.  However, XLink would need
   such a remapping for HTML and other formats.  A better analogy here
   is the namespace and DTD URI references for document instances.
   Here, as with file referencing above, people argue that it makes
   availability of link information uncertain and slow.  One counter
   is, again, authors can choose to include the file at the resource
   directly.  But the more likely solution is that the XLink
   semantics, as with HTML DTD and namespace information, would be
   hard-baked into the application processing the instance.  The URIs
   would never be downloaded -- it's only important that application
   developers know where they are so they can use them as
   specifications to make sure they are getting the hard-baking right.
   Actually, such hard-baking should make the XLink processing
   *faster*, since an XML parse would not be necessary.  Furthermore,
   the certainty of the XLink information would be the same for all
   distributions of a given program, so it could be given one robust
   test to determine the level of this certainty (and speed, for that
   matter).

In summary, I think we can and should develop remapping that meets
these requirements.  Doing so will give format crafters a strong
element-based approach for defining XLink semantics while giving
authors a choice to either also follow an element-based approach or
to use remappings provided by format crafters or other link-ologists.
People can choose not only whether or not to use remapping, but also
at what point in the file processing to do so.  I hope this posting at
least clarifies where some of the issues in applying XLink to HTML
lie.

-Lloyd

[1] http://lists.w3.org/Archives/Public/www-tag/2003Jan/0263.html

--
Lloyd Rutledge  vox: +31 20 592 40 93       fax: +31 20 592 43 12
CWI             net: Lloyd.Rutledge@cwi.nl  Web: http://www.cwi.nl/~lloyd
Post:   PO Box 94079    |  NL-1090 GB Amsterdam  |  The Netherlands
Street: Kruislaan 413/C |  NL-1098 SJ Amsterdam  |  The Netherlands

Received on Friday, 24 January 2003 10:49:23 UTC