This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4903 - Clarify or remove conformance language relating to document instances
Summary: Clarify or remove conformance language relating to document instances
Status: RESOLVED LATER
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.0/1.1 both
Hardware: Macintosh All
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-01 03:03 UTC by C. M. Sperberg-McQueen
Modified: 2007-08-03 18:29 UTC (History)
0 users

See Also:


Attachments

Description C. M. Sperberg-McQueen 2007-08-01 03:03:38 UTC
Section 3.2.1 of Structures reads in part:

    The value of the attribute MUST conform to the supplied 
    {type definition}.

I am not sure what this sentence means.  MUST is defined in section
1.5 of the spec (Documentation Conventions and Terminology) as 
describing requirements for conformance:

    Conforming documents and XSDL-aware processors are required to
    behave as described; otherwise they are in error.

The implication seems to be that section 3.2.1 is defining a rule
which XML instance documents must obey in order to conform to the XSDL
spec, and a further implication would be that XML instance documents
can usefully be spoken of as conforming, or not conforming, to our
spec.

I don't think XML instance documents are usefully regarded as
conforming or not conforming to the XSDL spec.  I think that this and
other instances (there are some) of similar usages are describing the
conditions under which document instances are valid against (or
conform to) a particular schema, not conditions under which they
conform to XSDL.

Two changes should be made: (1) every sentence that uses
conformance-related terminology of XML document instances other than
schema documents should be revised to refer to validity not
conformance, and (2) the conformance section of the spec should
explicitly state that validators and schema documents can conform to
the XSDL spec, and that document instances can conform to a schema (by
being valid against it) but not to XSDL.

Another paragraph in 3.2.1 causes even more difficulties.

    The {name} property [of an Attribute Declaration]
    MUST match the local part of the names of attributes 
    being validated.

What does this mean?  If a schema contains an Attribute Declaration
whose local name matches no attributes in the document instance, then
the {name} property of the Attribute Declaration has clearly not
matched the local part of the names of any attributes being validated.
That is, this rule, as formulated, has not ben obeyed.  Is the schema
then not a conforming schema?  Is the processor which performed the
match not a conforming processor?

If this sentence can be interpreted plausibly and given meaning in its
current formulation, then something needs to be added to the spec to
make that interpretation accessible to readers (including members of
the XML Schema WG).  Otherwise, this sentence and others which misuse
conformance-related terms should be recast to say what they mean.  (In
this case, I believe the intended meaning to be that the governing
attribute declaration for an attribute information item is found in
part on the basis of the attribute's extended name matching the target
namespace and {name} of the declaration.  Perhaps "The {name} and
{target namespace} property of the Attribute Declaration are used to
associate the declaration with attributes being validated.")
Comment 1 C. M. Sperberg-McQueen 2007-08-03 18:29:33 UTC
On its telcon today, the Working Group discussed this and other
recently opened issues in the issues database and concluded (not
without some pangs of regret) that for scheduling reasons it is not
feasible for us to resolve this issue, or any of the others in the
group, before we go to Last Call.

On whether the issue / proposal discussed here is worth pursuing or
not, the WG has taken no formal decision. Accordingly I am closing
this issue with a disposition of LATER, not WONTFIX.  That means the
Working Group believes that the issue may be resolved in some future
version of the spec, and encourages whatever Working Groups are
responsible for future versions of the spec to consider this issue
at an appropriate time.  (If this bug relates both to 1.0 and 1.1,
this resolution applies only to 1.1 and leaves undetermined how to
handle it vis-a-vis 1.0.)