Re: XLink: the architectural issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/ "Steven Pemberton" <steven.pemberton@cwi.nl> was heard to say:
| 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:

In the argument that follows, I think you're conflating two different
senses of the word "type". On the one hand, you mean "data type" and
on the other you mean something I guess I'd call "semantic type".

With the exception of XML 1.0 which restricts you to a single
attribute of type ID (an historical requirement that probably isn't
necessary) there's no way any spec can constrain the number of
attributes you provide of any given type.

[I'm reordering your prose slightly, no semantic change is intended]

| 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>

That's not a good analogy to XLink at all. The xlink:href attribute
doesn't prevent you from having other attributes of type URI, it only
prevents you from having two attributes with the name 'xlink:href'.

Suppose the XDate spec defined a createdOn attribute that identified
the semantics of "created on" according to the XDate spec. Then you
could only have one xdate:createdOn attribute, but most of us would
probably be willing to accept that an element has only one date of
creation (in the sense of the XDate spec, anyway).

Now, suppose XDate also provided a modifiedOn attribute. Then you
might posit that some applications need to keep track of more than one
date of modification. Now you have the apparent problem that you can't
say

  <para xdate:modifiedOn="2001-01-01" xdate:modifiedOn="2002-09-26">

True enough.

So then you need another mechanism. You could invent a mechanism that used
nested elements:

  <para>
    <modification xdate:modifiedOn="2001-01-01">...</modification>
    <modification xdate:modifiedOn="2002-09-26">...</modification>
  <para>

or you could invent a mechanism that allowed you to identify modification
date attributes in some out of band fashion:

  <para modifiedFirst="2001-01-01" modifiedLast="2002-09-06">

On the whole, the former seems like better markup design to me, but the
point could certainly be argued.

| 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.

Huh? If you're changing the semantic of an attribute in a schema,
you're going to be hard pressed to do so without also editing the
original documents.

If I've said <para modified="2001-01-02"> there's nothing you can
change in the schema to make that automatically link to the right
place without some edits (in the general case, at least).

|     * 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.

No, you're not limited to a single attribute of a given type.

| 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.

There's no question that the XLink WG failed to meet that requirement.
But you're playing a little fast and loose with it. I could satisfy
that requirement by providing an xlink:href-name attribute that
identified the name of the attribute with xlink:href semantics.

To meet the requirement that you should be able to have an arbitrary
number of attributes with the xlink:href semantic would be a different
story.

Following the principle that there are only three numbers in computer
science, I think it's perfectly reasonable to say that an element can
have zero xlink:href (no attr, no children), one xlink:href (by attr
or child), or an infinite number (by making them child elements).

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

Done. No specification can establish this restriction (with the
exception of XML 1.0).

You also want

     No specification should define semantics in such a way that they
     apply to only a single attribute with a given name

That's a lot harder to justify. And it would imply that I should be able to say
that the width of an image in my vocabulary is defined by the blort attribute, so

  <image blort="400">

is the same as

  <image width="400">

There might very well be some user communities that would find this useful,
but it's not clear that it's a broad requirement.

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | All our foes are mortal.--Valéry
XML Standards Architect |
Sun Microsystems, Inc.  | 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>

iD8DBQE9lMDwOyltUcwYWjsRAqa4AJ9g6PxY+NTyI9Op3ObeK0lFLziT/ACeNVWF
IhE9T5nj8LpJbdD+VIBWx3M=
=oNfU
-----END PGP SIGNATURE-----

Received on Friday, 27 September 2002 16:35:32 UTC