- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 06 Sep 2006 00:42:55 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3589 ------- Comment #1 from cmsmcq@w3.org 2006-09-06 00:42 ------- For the record, the references given in the description are to member-only documents, but the same text is visible in the working draft of 31 August 2006: http://www.w3.org/TR/xmlschema11-1/#impl-def-list) Note that the careful distinction Noah is trying to make between XML documents and infosets is rather undercut by other portions of our spec, which frequently refer to XML when on Noah's analysis it is of deep importance that what they really mean is not XML but the infoset is some XML or non-XML form. The conformance clause, for example, defines schema-document aware processors as those which "accept schemas represented in the form of XML documents" as described in the spec. (The 1.0 version of the conformance section was even worse, since the name it used for schema-document aware processors was "processors conformant to the XML Representation of Schemas".) So I observe that the confusion Noah is trying to combat, if indeed it is a confusion, has deep roots in the existing text. I have no particular attachment to the wording in the current working draft, but I do have an attachment to saying that it's implementation-defined whether an implementation can read schema documents in XML form, and implementation-defined whether it can read them in some other form which corresponds to an infoset. That means I'd prefer not to replace "implementation-defined" with "implementation-dependent", which means something different where I come from. In the QT specs, for example, implementations must document their behavior for implementation-defined things, but not for implementation-dependent things; I think it's important that this property be documented in any claim of conformance, so I want 'defined' not 'dependent'. And most practical implementations do not actually determine how schema documents are conveyed to them. The user does that at invocation time, by passing schema representations or names of schema documents in as parameters, or by setting or clearing flags which govern the search for components. All the implementation does is determine what possibilities are supported. So the wording "The exact form in which XML Schema documents are conveyed to a schema processor is implementation dependent" seems to me to state a falsehood. On the general question: I agree with Noah that he tends to see the infoset as primary and the XML as secondary, a serialization of that infoset, while I tend to see the XML as primary and the infoset as secondary, a description of (some of) the information in that XML document. I think the infoset spec similarly views the XML as central and the infoset a secondary, but whether that is so or not, I find the infoset-centric phrasing proposed in the description of this bug decidedly confusing. I think Alternative 2 is promising, though I would prefer that the definition be the other way round. So let me propose Alternative 3: [DEFINITION:] An -XML schema document- is an XML document or element whose information set is a schema document, as defined in this specification. and then It is implementation-defined whether a schema processor can read XML schema documents, or schema documents in non-XML form. (See Conformance (§2.4), which defines "·minimally conforming·" processors as those which cannot read schema documents in XML form, and "·schema-document aware·" processors as those which can.) If the WG prefers to avoid making capitalization alone bear the responsibility for distinguishing important terms, I will be happy (a) to substitute another phrase ('schema document in XML form' would work for me, although it's ugly), and (b) to adopt a name for our language other than "XML Schema", which is a proper noun distinct from a common noun phrase only by virtue of the capital S ("XSD" works for me, with or without an official expansion into something like "XML Schema Definition language").
Received on Wednesday, 6 September 2006 00:43:10 UTC