XLink: the architectural issue

Reading the recent raw minutes of the TAG discussion on XLink, I noticed
that the central architectural question was not addressed, which I will
express as follows:

    No specification should restrict the number of attributes of type X, for
any X, that
    another specification may use on an element.

Why not?

Well, the extensibility of XML is based amongst other things on being able
to use attributes from other namespaces. So if I want to add an attribute to
a paragraph:

    <para .... xyz:edited="2002-09-26" ...>

I can just do it, and namespaces makes it easy to achieve without clashes.

However, if some specification, say XDates, appropriates all attributes of
type Date, then you can't just do this, you have to look to see what other
attributes are already in use. So instead of

    <para abc:created="2001-01-01" xyz:edited="2002-09-26">
        Now is the time
    </para>

I would have to say

    <para>
        <created xdate:date="2001-01-01"/>
        <edited xdate:date="2002-09-26"/>
        Now is the time.
    </para>

and I can't ever design a 'simple date' element, because someone at a later
date may want to add another date to the element; so even if I only have a
single date, I still have to use the element-based form to allow for
possible future extensibility.

Similarly, you could be prevented from saying

    <image height="480" width="640"/>

and have to write

    <image>
        <height XInteger:val="480"/>
        <width XInteger:val="640"/>
    </image>

This is data-type transparency, tried out a long time ago in Fortran and
Basic, and generally recognized to be a Bad Thing: it reduces flexibility

    * If you decide, for instance that your edited date is now going to be a
link to a document listing all changes on that date (or whatever), you have
to edit all usage of that attribute in all your documents instead of just
changing a schema that says what its data type is.

    * If you want to change the data type of an attribute, you may be
prevented from doing so because you already have an attribute of that type
on the element.

We saw a first real-life example of this inflexibility caused by XLink
recently after XHTML 2 adopted the principle of allowing any element to be a
link (so that instead of

    <li><a href="...">My web page</a></li>
you can write
    <li href="...">My web page</li>
).

Members of the SVG group suggested it might be a good approach for SVG, but
it was pointed out you couldn't do it, because there are already hrefs on
some elements (and you can't have more than one).

This is the central, underlying architectural problem. Solve this (or
equivalently fix XLink so that it meets XLink requirement B2), and XHTML has
no unresolvable problem with using XLink.

Steven Pemberton

Received on Thursday, 26 September 2002 19:34:53 UTC