This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The following are, I believe, minor changes that would improve flow, correct typos, and/or clarify things for the reader. The working group is free to make any, all, or none of them. I require no feedback, I can live with any of them being ignored. 2.1 Overview of XSD from: This augmentation makes explicit information implicit to : This augmentation makes explicit information that was implicit Existing exp/word/imp juxtaposition makes my head hurt. 2.2.2.2 Element Substitution Group from: XSD provides a more powerful model supporting to : XSD 1.1 provides a more powerful model than XSD 1.0 supporting 2.2.3.1 Model Group from: items match one of the particles to : items match exactly one of the particles If you disagree, see the first paragraph of http://en.wikipedia.org/wiki/Disjunction for why the existing text is ambiguous unless the reader _happens_ to know you are talking about <choice> in this veiled way. 2.2.3.2 Particle "[Definition:] A particle P is said to accept or recognize the members of L(P). Similarly, a term T accepts or recognizes the members of L(T)." Modulo the substitution of words like particle/P for model group/G, these Definitions (apparently of "X accepts" etc) are dups of those in the preceding section. If the P/G difference is sufficient to make those different terms in your eyes, I think you will successfully fool most readers. 2.2.3.3 Attribute Use "attribute declaration within a complex type definition is embedded within an attribute use" This appears to say that attribute use components only correspond to embedded, not referenced, uses. Just confirming that is so, I thought both embed/ref would result in attr-use. 2.2.4.2 Type Alternative FYI: "A type-alternative component" name is not hyphenated everywhere in later sections, if it should be. 2.3 Constraints and Validation Rules - Schema Component Constraint from: components at all. Located in the to : components at all. They are located in the Otherwise "Located..." sentence has no subject. Alternative: ; l also in 2.3 Constraints and Validation Rules - Schema Representation Constraint 3.1.3 The Mapping between XML Representations and Components from: URI reference to : URI-reference RFC 3986 appears to always hyphenate this, FYI. 3.2.2.2 Mapping Rules for Local Attribute Declarations "...attribute declaration (see below)..." I usually interpret this to mean the first "thing" below. In this case you are referring to the second. Perhaps a link? 3.2.2.2 Mapping Rules for Local Attribute Declarations from: the {attribute declaration} of the attribute use just described, to : the {attribute declaration} of the preceding attribute use, Alternative: "above" 3.3.4.4 Element Locally Valid (Type) "...definition·, ·lax assessment· is performed, ..." I'm not sure how to fix this. It feels like there is a missing connector before lax assessment is performed, but the preceding but-and-otw-neither-nor maze could be defeating my attempts to properly group the terms. 3.3.5.1 Assessment Outcome (Element) from: 1.2 otherwise invalid.. to : 1.2 otherwise invalid. 3.3.5.4 Element Validated by Type - [type definition name] from: the ·type definition·'s {name} property is to : [·type definition·]. {name} is Note: {} might need to be [] I did not dig back to find the notation you introduced earlier for this kind of case. 3.3.5.4 Element Validated by Type - [type definition name] from: The {name} of the ·type definition·, if the {name} is not ·absent·. to : The {name} of the ·type definition·, if the {name} is present . Might be worth a global scan for "not present" and "not absent", other examples of "not absent" definitely exist but I will not enumerate them here. e.g. 3.3.4.3 Element Locally Valid (Element) Validation Rule: Element Locally Valid (Element) clause 1 3.4.2.3 Mapping Rules for Complex Types with Complex Content "one with neither <simpleContent> nor <complexContent> as a child (discussed in Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1))" from: in Mapping Rules for Complex Types with Explicit Complex Content (§3.4.2.3.1)) to : in Mapping Rules for Complex Types with Implicit Complex Content (§3.4.2.3.2)) Simple copy/(forgot to) tweak omission. EXplicit covered 2x in this paragraph, IMplicit covered 0x. 3.4.2.3.1 Mapping Rules for Complex Types with Explicit Complex Content FYI: formatting glitch, {derivation method} (in browser window on screen, not print) runs over box bottom's border 3.4.2.6 Examples of Complex Type Definitions FYI: 2nd Example box uses different style (no "intro" text at top) than others surrounding it. 3.4.4.4 Attribution of Elements to Particles from: attribute wildcards, particles and open contents on the other, to : attribute wildcards, particles and open content on the other, 3.4.4.4 Attribution of Elements to Particles "the {attribute declaration} of an Attribute Use, then the item is attributed to that attribute use" I found myself, after the ibuprofen kicked in, wanting to use a different verb than attribute for this role, like assigned or mapped. Then I noted that when defining context-determined decls later in this section, you do switch to "associate". Changing "attribute to" -> "associate with" more widely (even globally) would be a clarifying action IMO. Section 3.8.4.1 Language Recognition by Groups uses "match": "... the sequence of ·basic particles· which the [element] items of S match, in order, is a path of S in M." 3.4.5.1 Attribute Default Value FYI: formatting glitch, evident in Firefox 2 and 3 on Windows XP (have not tested others). 2-item bullet list near end of section, first word "Add" of each item was bulls-eyed by the bullet e.g. "Add the binding of P to N to..." 3.8.1 The Model Group Schema Component "By 'indirectly' is meant particles... " 3.8.2 XML Representation of Model Group Schema Components in XML Mapping Summary for Particle Schema Component tableau from: A model group as given below: to : A model group as given below. 3.10.1 The Wildcard Schema Component FYI: formatting glitch up-arrows appear around item 6 in the numbered list 3.10.1 The Wildcard Schema Component - {process contents} controls ... lax "If the item has a uniquely determined declaration available, it must be ·valid· with respect to that definition," Notice the switch from decl to def in the same sentence. Looks wrong from here. 3.10.4.2 Wildcard allows Expanded Name FYI: formatting glitch up-arrows appear around item 2 in the numbered list, and around "Informally..." 3.10.6.2 Wildcard Subset FYI: formatting glitch up-arrows appear around item 3 in the numbered list 3.11.4 Identity-constraint Definition Validation Rules - last parag from: treated as equal , for purposes to : treated as equal, for purposes 3.12.2 XML Representation of Type Alternative Schema Components "type alternative schema componentType Alternative is" 3.13.4.1 Assertion Satisfied - 2.3.1.3 note 1 from: This clause provides type information to simple contents of elements, to : This clause provides type information to simple element content , 3.16.7.4 Built-in primitive datatypes "primitives are supported" missing: datatypes "primitive types can be supported" missing: data "Types ·automatically known· to a processor, whether primitive or derived" missing(?) Data+t "specify new primitive types" missing: data 4.2.4 Overriding component definitions - Schema Representation Constraint: Override Constraints and Semantics 2.2+ Numbering has little phoenetic value. How about from: call the overridden <schema> item D2 to : call the overridden <schema> item Old and from: and the overriding item's parent <schema> item D1 to : and the overriding item's parent <schema> item New Another alternative: OI (old item) and NI 4.2.5 References to schema components across namespaces from: components not within that document's target namespace to : components outside that document's target namespace Alternative: re-use existing term from next sentence = foreign target namespace (note: not formally defined, but I think fine) 4.2.5.1 Licensing References to Components Across Namespaces "external component references" - nb: in italics, but not a [Definition:], though it sure looks like it wants to be one. Harmonize with 4.2.5 text that uses "not inside" and "foreign". 4.3.2 How schema definitions are located on the Web "This section introduces a set of normative conventions..." normative conventions? tilt 4.3.2 How schema definitions are located on the Web - bullet 1 "...·assessment· is undertaken on the document element information item of the specified document" from: specified document to : specified instance document To distinguish from "schema document" which I get it is theoretically possible but not the usual intent. 4.3.2 How schema definitions are located on the Web - numbered item 3 FYI, in case unintentional, largely dups content in 1.3.1.2 and 2.6.x 4.3.2 How schema definitions are located on the Web - ex after numbered item 4 FYI: 2nd ns line is too long for 8.5x11 printing using default margins (FF2,3) It is truncated after Transform.xs on the 2nd schemalocation. This does occur in a few other places, will not enumerate them all. 5.1 Errors in Schema Construction and Structure from: The three cases described above to : The two cases described above or, more durably, to : The cases described above (I realize you didn't expect a kind of Spanish Inquisition, Cardinal Biggles) 5.2 Assessing Schema-Validity from: refers back to the ·validation root·. . to : refers back to the ·validation root·.
A wording proposal intended to resolve this issue in part is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6008.html See also the cover note at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Mar/0005.html
FYI, the draft ends prematurely in the middle of 3.16.6.2 > http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6008.html --- > [3] 6008 comments that I don't know how to address > 4.2.5.1 Licensing References to Components Across Namespaces > "external component references" - nb: in italics, but not a [Definition:], > though it sure looks like it wants to be one. > Harmonize with 4.2.5 text that uses "not inside" and "foreign". To clarify: either "external component references" is a definition, in which case it should be marked up and treated like all other definitions in this document, or it is not, in which case it should not be italicized. The italics suggests to average readers that those words constitute a term being defined, based on similar usage in other contexts where specific markup for definitions is less rigorous. > [4] 6008 comments that I don't understand > 3.4.2.6 Examples of Complex Type Definitions > FYI: 2nd Example box uses different style (no "intro" text at top) than > others surrounding it. Ignore it, not sure what I was thinking. Note that this first example lacks some sort of "code snippet" markup (with associated grey bkgrnd on screen) that others in this section do have. > 3.10.1 The Wildcard Schema Component > FYI: formatting glitch up-arrows appear around item 6 in the numbered list Ignore: I do not see them either now, using 1/30 draft. Possibly a browser rendering issue, since fixed. Same for following. 3.10.4.2 Wildcard allows Expanded Name > FYI: formatting glitch up-arrows appear around item 2 in the numbered list, > and around "Informally..." > 3.10.6.2 Wildcard Subset > FYI: formatting glitch up-arrows appear around item 3 in the numbered list
Proposed amendment: in 2.2.3.1 from: items match one of the particles to : item match one or more of the particles not : items match exactly one of the particles for two reasons: (1) our choice construct should have the same meaning as in regular expressions -- the unique particle attribution constraint should be a separate constraint imposed on 'choice', not built into it by definition. And (2) even while obeying UPA, an XSD 1.1 choice can have two matches for a particle (element on the left, wildcard on the right). in 3.8.1. revert the insertion of 'implicitly' -- elements can be present implicitly (but being in an appropriate substitution group), but particles are only present directly or indirectly.
6008 (John Arwe): [schema11] small presumably editorial bugs. http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6008.html Summary: several small stylistic fixes. There has been discussion in Bugzilla; amendments are needed. SG's recommendation: We only have a partial proposal. I can review items I didn't cover to see whether there is anything else I can do. MSM's recommendations: quick. - In 4.2.5.1, deal with John's first point by untagging the phrase 'external component references'. The sentence then reads Thus, the <import> element information item identifies namespaces used in external component references, i.e. those whose ·QName· identifies them as coming from a namespace different from that of the enclosing schema document's targetNamespace. The only different from status quo is that 'external component references' is roman, not italic. - In 2.2.3.1, for the item that now reads Disjunction (the element information items match one of the particles). Do NOT adopt JA's proposal Disjunction (the element information items match exactly one of the particles). Instead, write Disjunction (the element information items match one or more of the particles). for the reasons given in bug 6008 comment 3. - Adopt what we have, note that issue is editorial, come back to it (and deal with more of it?) after CR. Sandy has provided a pointer that enumerates the parts of this issue that are to be done later. http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Mar/0005.html
I'm happy with the choices made on all of these, and thank the editors for considering them. I see no evidence that the SML wg endorsed these comments, so I don't think their feedback needs to be solicited, but please correct me if I'm wrong and I will put it on next week's agenda.
Further changes to the spec proposed on the basis of these comments were adopted by the XML Schema WG at its call of 19 June 2009; most of the changes are shown in the proposal at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6008a.html Amendments were made, as described in the minutes at http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Jun/att-0006/2009-06-19telcon.html (member-only link) With these changes, the XML Schema WG believes we have resolved all the points raised in this bug report, to the degree it's possible to do so. (A few suggestions have not been taken, as indicated in the minutes and various email messages pointed to from them, for the reasons given there.) John, we thank you again for your careful reading and painstaking comments. You've already indicated that you are happy with the resolution of this bug report, independent of details, so I will mark this issue closed now.