Re: Erratum in Normative References

On Oct 21, 2014, at 6:01 AM, Hugh Cayless, Ph.D. wrote:

> Hi, 
> 
> Under the Normative References section in http://www.w3.org/TR/xmlschema-2/ at the citation for XML 1.0 (http://www.w3.org/TR/xmlschema-2/#XML) the document links to the August 14th, 2000 Working Draft (http://www.w3.org/TR/2000/WD-xml-2e-20000814). The latter document states in its Status section: " This document should not be used as reference material or cited as a normative reference from another document." That statement indicates to me that the link doesn’t belong in the Normative References.
> 
> I’d like to ask that the link to the WD be updated, or that the fact that the link’s target has been superseded be noted in the Errata.
> 
> The Working Draft uses a now-outdated production for Name (http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Name), which relies on Letter (http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Letter) and BaseChar (http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-BaseChar). The latter productions "are now orphaned and not used anymore in determining name characters" according to http://www.w3.org/TR/REC-xml/#CharClasses. I’m currently trying to convince an implementor that the fact that the XML Schema document links to an outdated working draft of XML 1.0 does not mean the outdated Name production therein is still law for XML datatypes. Surely the production from the latest edition of XML 1.0 should apply?
> 
> Thanks very much,

Another personal reply, not speaking for any responsible WG.

The reference to XML 1.0 in the second edition of XSD 1.0 Part 2 is
the same as the reference in the first edition.  This may, as Liam
Quin has suggested, have been an oversight on the part of the editors.
But it is not certain that it was an oversight.

As later discussion in the XML Schema working group established, there
are several schools of thought regarding references to specs later
published in revised versions.  If a spec S ('source') refers
normatively to a version V of some other spec T ('target'), the
reference may be interpreted as meaning:

  1 Conforming implementations of S must conform to (the relevant bits
    of) version V of T.  Earlier and later versions of T are
    irrelevant.

    Let's call this 'tight binding'.

  2 Conforming implementations of S must conform to (the relevant bits
    of) T, as defined in version V or later.  The choice of which
    version of T to support will necessarily be made (and documented)
    by the implementers implementing S.

    Let's call this 'loose binding'.

If your account is taken at face value, you may represent a third
group, which would hold that:

  3 Conforming implementations of S must conform to the most recent
    version of T.   The fact that version V is specified in the
    reference is a bibliographic artifact and has nothing to do with 
    the conformance requirements of S.  

    I'll call this 'newest binding' (although I am sorely tempted by
    'action at a distance').

Clarification of the question -- let alone resolution -- is made
difficult by the fact that almost everyone agrees on the principle
that the question is simple, the answer obvious.  Discussion is thus
quite obviously pretty much a waste of time.  It's just that the three
groups disagree on the identity of that obvious answer.  The effect
this can have on quality of discussion is well illustrated by the
discussion of this question by the W3C's technical advisory group
(TAG) a few years ago [1], [2], in which it was seriously argued that
it was wrong for WGs to have a choice about whether they meant a
normative reference to involve tight binding, loose binding, newest
binding, or something else.

Loose binding corresponds to the policy mentioned in many ISO
specifications:

  The following standards contain provisions which, through reference
  in this text, constitute provisions of [spec S].  At the time of
  publication, the editions indicated were valid.  All standards are
  subject to revision, and parties to agreements based on [spec S] are
  encouraged to investigate the possibility of applying the most
  recent editions of the standards listed below.  Members of IEC and
  ISO maintain registers of currently valid International Standards.

In favor of loose binding is the desire to ensure that improvements to
T can be enjoyed by implementers and users of S (think, for example,
of the development of new URI schemes and the implementers and users
of HTML browsers).  Against loose binding is that it somewhat weakens
the interoperability story for spec S.

In favor of tight binding is the fact that the group responsible for
spec S has has not, after all, had a chance to read later versions of
T, and there can be no guarantee that the idiots^H^H^H^H^H^H^H groups
responsible for T have not introduced changes incompatible with S
(like eliminating a technical term relied on by S).  So tight binding
gives us a stronger interoperability story.  Against tight binding is
the argument (persuasive to some people) that it would be crazy for
W3C specs to be harder to update than ISO specs. 

The XML Schema working group at W3C included representatives of both
tight and loose coupling (both as a general policy, and as the obvious
interpretation of normative references not otherwise described).
Proponents of tight coupling might logically have opposed an update to
the reference, on the grounds that later versions of XML [3], [4], [5]
might differ substantively from the version relied on by initial
implementations of XSD part 2.  Proponents of loose coupling might
logically have concluded that a change to the reference is
unnecessary, since implementors already have the ability to support
later versions of XML, or even that a change would be undesirable,
since implementors who relied on the original normative version should
not have the rug pulled out from under them.

So there is absolutely no guarantee that a proposal to update the
reference to point to the then-current XML 3e would have gotten
consensus in the XML Schema WG.  Even updating the references in XSD
1.1 routinely led to difficult negotiations.  For discussions of these
issues in the XML Schema wg, see [6] and the thread begining at [7].
Bear in mind, as you read, that all of the objections against
requiring or allowing support for XML 1.1 also apply to XML 1.0 5e.  I
do not have the time or energy right now to pursue the decision
records further to see what happened to the change proposal in [7]; my
recollection is that it was rejected.  Eventually (in 2006), the WG
did add wording to the 1.1 spec mandating a loose-binding
interpretation of the normative reference [8].

Because the issue of support for the radical changes in character
classing in XML 1.1 and XML 1.0 5e was so contentious in the XML
Schema working group, and because the debate over whether the existing
normative references were to be taken in the sense of loose or tight
binding was equally contentious, I think it would be a flagrant abuse
of the W3C errata policy to make the change requested.

I sympathize with the commenter's desire for a loose binding between
the XSD and XML specs, but the tight-binding interpretation of the 
programmer he is trying to persuade cannot, I think, be refuted on the
basis of the specs.


[1] http://lists.w3.org/Archives/Public/www-tag/2009Oct/0075.html (and
ensuing thread)
[2] http://lists.w3.org/Archives/Public/www-tag/2012Jan/0043.html (and thread)
[3] http://www.w3.org/TR/2000/REC-xml-20001006
[4] http://www.w3.org/TR/2003/PER-xml-20031030/
[5] http://www.w3.org/TR/2004/REC-xml-20040204/
[6] http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0027.html
[7] https://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Jun/0068.html
[8] https://www.w3.org/Bugs/Public/show_bug.cgi?id=1838



-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************

Received on Tuesday, 28 October 2014 04:16:27 UTC