Re: Erratum in Normative References

On little anecdote about the dangers of tight binding is the reference in the XSLT 1.0 spec, which defined the semantics of format-number() by reference to JDK 1.1:

The format pattern string is in the syntax specified by the JDK 1.1 DecimalFormat class.... The format pattern must not contain the currency sign (#x00A4); support for this feature was added after the initial release of JDK 1.1.

So there's a pretty clear intention that the reference was a "tight" one; new features added subsequently to the JDK would not be inherited by XSLT.

This caused no end of practical difficulties. Firstly, the relevant version of the JDK documentation became pretty inaccessible, and the links to it were broken. Secondly, the JDK spec was full of bugs, which were fixed or clarified in later JDK versions, and it wasn't clear whether XSLT implementations were supposed to implement every bug faithfully.

We've generally got better in our neck of the standards woods at getting this right, I think. We still have issues, some of the specs we refer to have a long history of buggy releases (for example the URI specs), and the policies for correcting or revising the specs are highly variable.

Frankly, as an implementor implementing a spec some years after it was published, I think you have to be pragmatic. What works for your users? If the world has moved on to Unicode 18.5, then the fact that you are implementing a spec that refers to Unicode 3.1 doesn't mean you have to take it literally. Your users want interoperability, and that doesn't just mean identical behaviour to other implementations of the same spec, it means the ability to use your software as a components of systems that contain lots of components implementing different specs published at different times by different people.

Another anecdote from the past: when I worked for ICL we produced an X.400 email system. A customer in the Netherlands wanted to use it alongside an X.400 email system from DEC. Interoperability between the two systems was good, except that many of the email addresses already in use on the DEC system used non-ASCII characters. The X.400 standards didn't allow non-ASCII characters in email addresses, but DEC had provided an extension, and the customer wasn't interested in our product if it couldn't send mail to those addresses. So we implemented the same extension. Interoperability is the goal; standards conformance is only a means to that end.

Michael Kay
Saxonica
mike@saxonica.com
+44 (0) 118 946 5893




On 28 Oct 2014, at 04:16, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:

> 
> 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 10:19:11 UTC