[Bug 25149] Normative references to unstable documents must be removed before publication

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25149

--- Comment #7 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
I've been working through the list of normative references, checking for (a)
stability of the target and (b) the nature of the normative dependency.  Some
points seem worth recording, for the record.

(1) Character model (already dealt with in comment #4); not stable, needs to
become a non-normative reference.

(2) Polyglot.  Some references appear non-normative in force and can be left
alone (or moved into notes).  The references in section 6 on the XHTML
serialization method have normative force; the relevant rules in the Polyglot
spec are brief and can be copied into the serialization spec with a note
indicating their provenance, and optionally a provision that conforming
implementations MAY adjust their behavior to match that specified in any future
Recommendation version of the Polyglot spec, with (or without) requiring or
recommending a user option to control the behavior. 

(3) RFC 2854.  Only reference is in a note; should be moved to non-normative
references.

(4) RFC 3236.  As for RFC 2854.

(5) XML Schema.  Only reference is in a note; should be moved to non-normative
references.

(6) XSLT 3.0.  The following references to XSLT 3.0 appear to me to be
non-normative in force, so they can be left alone (or moved into notes, or
rephrased appropriately):

  - Abstract
  - 1 Intro
  - 9 Character maps (refers reader to XSLT 3.0 for examples)
  - 10 Conformance (mentions XSLT as a possible host language)

The following have normative force, but could easily refer to XSLT 2.0 instead.

  - 9 Character maps (reference to disable-output-escaping as an XSLT feature)

The following have normative force, and it's not immediately obvious to me how
to rewrite them to avoid a normative dependency on XSLT 3.0 (it may be possible
but not obvious; it may be obvious but not immediately obvious; it may be
immediately obvious to any intelligent observer but not to me):

  - 1.1 Terminology

    Where this specification indicates that an XSLT instruction is 
    evaluated, the behavior is as specified by [XSL Transformations 
    (XSLT) Version 3.0].

  - 2 Sequence normalization (reference to XSLT 3.0 deep copy)

  - 3.1 Setting Serialization Parameters by Means of a Data Model Instance 
    (the static context component "Set of available instructions" is 
    defined as including the set of all XSLT 3.0 instructions)

(7) HTML 5.  Some references (I won't list them) have no particular normative
force; others seem to me to require a normative reference, or else the
replication of constraints from the current version of HTML 5.  Copying
constraints will require us to decide what conforming users of Serialization
should do when HTML 5 progresses, if it changes any of those rules.  The few
references that seem most clearly normative to me are:

  - In 6 XHTML Output Method, HTML5 is listed as a source of information to use
when deciding to recognize an element as an HTML element.

  - 6.1.4 XHTML Output Method: the indent and suppress-indentation Parameters,
HTML 5 is the source of information about which elements are phrasing elements.
 7.4.3 HTML Output Method: the indent and suppress-indentation Parameters
refers to HTML 5 for the same information.

  - 7.2 Writing Attributes (in the HTML method) refers to HTML 5 as one source
of information about which attributes to consider booleans. 

I suppose that in all of these cases, we could change the wording to
generically refer to existing and future definitions of HTML, and make it
implementation-defined which versions of HTML are binding for purposes of
identifying HTML elements, phrasing elements, and boolean attributes.  If we do
that, we should also do it for the list of void elements (already copied into
the serialization spec, presumably for reasons like those occupying my mind
today).

It's clear that removing the normative dependencies of Serialization 3.0 is
going to involve changes large enough to require WG consideration and approval.
 The editors will set about preparing a suitable change proposal.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 27 March 2014 01:23:30 UTC