Comments/queries on XLink PWD of 21-February-2000

Serious concerns:

1) Although 'must' etc. are used as per IETF whatever, no discussion
of error behaviour is provided, i.e. in section 4.3 point 2, nothing
is said as to what "observing the mandatory conditions" means --
complain, halt and catch fire, what?

2) The definition of 'application' in the (presumably normative)
terminology section (1.3) implies that a conformant processor of _any_ 
document with linked-from resources must recognise that fact.  This is 
clearly to strong a requirement in the case where the document in
question contains no linkset information.

3) I saw nowhere which made clear whether the term 'element'
throughout, and particularly in section 4.2, refers to an Element
Information Item as defined in the Infoset PWD, or to a character
sequence in an otherwise non-well-formed non-XML document, or what.

4) I think if you're going to describe the 'show' attribute as having
QNames as values, then ignoring the default namespace declaration is a 
serious mistake.  If it's a QName, then its qualification is
determined by XML Namespace REC rules.  If its qualification is _not_
determinied by those rules, it's not a QName.  I think you have two
options:

 a) Describe it as a union of {new,replace,embed,undefined} with
    QName, with a hack explaining that in cases where there's no default
    NS declaration in scope the ambiguity is resolved in favour of the
    privileged interpretations;

 b) Describe it as a QName, and reserve the un _qualified_ versions of
    new,replace,embed,undefined.  This would mean if there is a default
    NS declaration in scope, you'd have to switch it off with "xmlns=''"
    before you could specify the special values;

 c) Describe it as a QName, and switch to using xlink:new,
     xlink:replace, xlink:embed, xlink:undefined.

 d) Combine (b) and (c), i.e. reserve _both_ (unqualified) 'new' and
    'xlink:new', etc.  This would give you a way of avoiding the necessity
    of undeclaring the default NS.

On balance I prefer (c) (it matches the use of xlink:extended-linkset
for 'role'), but could live with (b) or (d).

5) In 3.1.5, I'm not sure that requiring sensitivity to
role=xlink:external-linkset _anywhere_ in a document is coherent -- at 
the very least it seriously disadvantages streaming processors.

Observation:

I note that the concerns raised in section 2.5, and in particular the
issue of legacy 'naked' href, can probably be addressed by XML
Schema.  I guess I hope the timing is such that you can include an XML 
Schema for XLink in the REC.

Minor editorial problems:

1) All the contributing systems mentioned in 1.1, including HyTime and 
TEI as well as Dexter etc., should have references.

2) Please clarify the interaction of xlink:href and XBase.  In
particular, I can't tell whether 

  <foo xlink:type="simple" xlink:href=""/>

is always OK, always broken or depends on XBase.

3) The second figure in 3.1.5 has xlink:extended-linkset where it
should have xlink:external-linkset.

4) 3.4: "The URI-reference must be receive" -> "The URI-reference must receive"

5) last line in 3.6 intro above 3.6.1: "actuated=" -> "actuate="

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Thursday, 9 March 2000 10:44:05 UTC