HTML WG Last Call Comments, part 2 of 2

HTML WG Last Call Comments on Xlink
Part 2

(Apologies for these comments being late.)

These are the promised detailed comments, after the larger philosophical
issues in part 1.

Abstract
'It uses XML syntax to create structures that can describe the simple
unidirectional hyperlinks of today's HTML'
It may be a difference of opinion about what 'describes' means here, but a
better wording would be
'It uses XML syntax to create structures that describe behavior similar to
the simple unidirectional hyperlinks of today's HTML'

2. Xlink markup design
See comments later on the title attribute.

3. Xlink elements and attributes
'linkset' used here but not defined

3.1 Extended links
The last example is hard to understand. The DTD fragment doesn't seem to
allow several 'course' elements, and yet they are in the markup.

3.1.1 Local Resources for an extended link
There is a possibility of confusion in the use of the term 'local resource',
even though you define the term, since many people may think of a local
resource as being something inside the document. A fragment in the document
may well be a non-local resource in a link in the document. Maybe a
'contained resource' might better express the intent.

3.4 Locator attribute
"The URI reference must be receive XML Base processing."

3.5 Semantic attributes
Constraint: role Value
You reference the Namespaces Recommendation, but we can find no part of that
that allows Qnames to be used in this way as attribute values. What you are
proposing here seems to be an extension to Namespaces that hasn't been
agreed within W3C.

The description of the title attribute here is very vague, and we wonder if
it should be in Xlink at all. Since such an attribute is turning up in
several W3C recommendations, it seems better to be applied to XML as a whole
rather than each application adding a new, slightly different, version.

3.6 Behavior attributes
Seeing how much trouble you went to to get the onLoad and onRequest names
right, it is surprising that you still use the name 'Show' for this
attribute. It seems to us far too visually oriented, when many uses, indeed
many user agents, may have no visual semantics involved at all, and yet
still use this attribute. We suggest a more neutral name, such as 'effect'.

We feel that the semantics of 'show' are too vaguely defined (and too
visually oriented, using the word 'display'). We had assurances from the
Xlink group at your face to face last Summer that 'embed' also covered
non-visual embedding such as scripts, and we would like to see that made
explicit.

Steven Pemberton
For HTML WG

Received on Monday, 10 April 2000 10:44:09 UTC