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 passages whose interpretation I was unsure of. 2.2.1.1 Type Definition Hierarchy "A type defined with the same constraints as its ·base type definition·, or with more, is said to be a restriction." "A complex type definition which allows element or attribute content in addition to that allowed by another specified type definition is said to be an extension." I can read these together to say that a single type def may be both an extension and a restriction, although I know XSD syntax does not allow that. The obvious case is a "vacuous extension", i.e. one that adds no new element or attribute content. Yes? 2.2.1.2 Simple Type Definition "A simple type definition is a set of constraints on strings and information about the values they encode, applicable to the ·normalized value· of an attribute information item or of an element information item with no element children." This appears to say mixed=yes => never a simple type def. Yes? 2.2.2.1 Element Declaration "...by triggering identity-constraint definition ·validation·." My brain thinks you are calling out 'i-c def validation' as a special term, but the usual presentation evidence of that (dots on either side of a link) is absent. 2.2.2.2 Element Substitution Group "...name and content of an element must correspond exactly to the element type referenced in the corresponding content model." Seems to a novice reader equivalent to saying "to the governing type decl". If so, using that term _might_ be clearer even though it's a forward reference. Alterntively, their equivalence could be noted if it is in fact true. 2.2.2.2 Element Substitution Group "...Through the new mechanism of element substitution groups, " New? It was in 1.0. I realize via further reading it has changed (multi-head now allowed) but that seems like "improved" not "new". If the attempt was to distinguish it from "substitution groups", sans "element", I don't think it does so. 2.2.4.2 Type Alternative "A type-alternative component (type alternative for short) associates..." The parenthetical seems to be here only for this component type. Seems like it should be done consistently (all or none). 3.3.2.1 Common Mapping Rules for Element Declarations - XML Mapping Summary clause 2 "2 otherwise (the <alternative> has a test) a Type Alternative with the following properties: Property {test} Value ·absent·." <alternative> HAS a test, {test} value is ABSENT. ??? 3.3.1 The Element Declaration Schema Component FYI: The two paragraphs beginning with "Element declarations are potential members of the ·substitution groups·," are pretty hard to actually understand (the first more than the second, but the first depends on the second so they are linked). 3.3.4.3 Element Locally Valid (Element) Validation Rule: Element Locally Valid (Element) clause 1 When D and E both have namespace values of "absent", clause 1 seems to output "never valid". Is that that intent, do I mis-read? 3.3.5.1 Assessment Outcome (Element) "...with a [schema information] property..." FYI: Since I read this front to back, at this point I had not seen anything to tell me that 1.1 was introducing new properties, so this confused me. It eventually became clear of course. I wonder if a link or definition is warranted for new chunks like this. 3.3.5.2 Validation Failure (Element) FYI: By this point, I figured out that you were defining new PSVI in some of the []'s since I saw the definition before the usage. [schema error code] got me to asking questions about its type (string? qname?) that I realize now I never asked about the PSVI properties I grew up with, so I'm not sure if those questions are actually fair. It does seem that there might be some value in making the error codes Qnames, to enable Schema processors invokers to clearly distinguish between "official standard" error codes and additional (potentially more informative) codes provided by the schema processor impl. I have heard folks operating in the business layer complain that standard schema error messages are inadequate generally to tell a user what in the instance is wrong, and therefore they use Schematron etc to pre-process instances and issue more domain-user-friendly messages. 3.3.5.2 Validation Failure (Element) "Note: If more than one ... fails to be satisfied," applies equally well to [schema error code], no? 3.3.5.4 Element Validated by Type "The first (·item isomorphic·) alternative above ..." FYI, could be read as "nearest" or "immediately preceding" rather than your intent (I think) of "first in this section". Short of a link, hard to truly disambiguate. 3.4.2.3 Mapping Rules for Complex Types with Complex Content XML Mapping Summary for Complex Type Definition with complex content Schema Component clause "4.2.1 If the {base type definition} is ... as per clause 4.1 above;" I think you need to add "..., substituting extension for restriction;" or the language lawyers will have you 3.4.4.1 Context-determined Type and Context-determined Type Table "partial functional mapping" may be using a precise term w/o definition, else it seems mushy ("partial" could be 0.0001%) " This mapping serves as a context-determined type ..." important enough to define, but it's not clear why. I recognized it was used later when I saw it come up again, but by then I was too tired to compare the two. Some hint as to the reason this term is important enough to warrant its own name might help it stick better. Just an idea. Same thing occurs in definition of "context-determined type table" further in this section (consistent, good, good) 3.7.2 XML Representation of Model Group Definition Schema Components - final parag "The name of this section is slightly misleading,...Also note that ..." Probably should be a Note: paragraph. 3.10.4.2 Wildcard allows Expanded Name Validation Rule: Wildcard allows Expanded Name - clause 4 The wording of this VR is "odd". At the top level it starts "...all of the following must be true:" Clause 4 of the ALL is itself an If-Then however. What does it mean for an If-Then to be true? Does the ALL wrt 4 AND in the result of 4's If condition? It's Then clause? (how does one even AND an "action"?) 3.13.4.1 Assertion Satisfied "Note: It is a consequence of this construction that attempts to refer, in an assertion, to ... will be unsuccessful." unsuccessful, meaning: error? "just" never true? must ...? Might a processor able to detect this usefully inform its invoker (e.g. via a warning code/msg)? I think the answers are likely "just never true" and "yes, but might not be practical to detect", but that's based on my dealings with 1.1 authors, not this spec. Is there potentially any ability for another spec (like SML V-Next, with its deref()) function to change this behavior without running afoul of 1.1? "just never true" suggests it might be. 4 Schemas and Namespaces: Access and Composition I trundled off to find whether "...namely access to one or more schemas" was a sensible statement, given some of the discussions we've had in the SML wg about words like "schema" vs "schema document" and what each means (is there more than one schema for a given assessment episode? etc.). I discovered that "schema" is in fact not formally defined, that is, not in the glossary and lacking the usual "[Definition:]" rendering. Seems like a fundamental item to define, and I think you have a serviceable def in 2.1 already: > 2.1 Overview of XSD > An XSD schema is a set of components such as type definitions and element declarations. 4.1 Layer 1: Summary of the Schema-validity Assessment Core - bullet 2 "no definition or declaration changes once it has been established;" Someone is going to have to help me reconcile that statement with the existence of redefine and override, which seems to do exactly that. 4.2.4 <override> "Also, existing XSD processors have implemented conflicting and non-interoperable interpretations of <redefine>, and the <redefine> construct is ·deprecated·. " Circular logic to deprecate <redefine> in this spec and then use that decision to justify the need for <override>. 4.2.5.1 Licensing References to Components Across Namespaces "There is no need, for example, to import...HTML..." This may be factually true, but is not the point _why_ this is true? This point has been omitted. It is not intuitively obvious from the text here, my suspicion would be that Schema for Schemas has processContents=skip at a convenient place. Same question arises in the Example tableau. The answer might usefully be annotated in the <documentation> as a comment. 4.2.5.1 Licensing References to Components Across Namespaces "...prefixes declared with namespace declarations in the normal way..." 1.4 Dependencies on Other Specifications says, in essence, that all 1.1 dependencies on XML Namespaces are via Datatypes, i.e. may be NS 1.0 or 1.1 depending on the datatypes provided by the processor. So "normal way" means according to either NS spec right, Schema has nowhere that it depends on a XMLNS 1.1-only "feature"?
The SML working group chose to endorse this bug on its call of 2008-09-11
A response to the first twelve of the points raised here has been posted to the XML Schema comments list at http://lists.w3.org/Archives/Public/www-xml-schema-comments/2009AprJun/0016.html The changes mentioned in that email can be seen in context at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6009.html (member-only link) As and when I do further work on this issue, I expect to update that proposal.
A second (and final) installment of responses to these comments is now in the comments list archive at http://lists.w3.org/Archives/Public/www-xml-schema-comments/2009AprJun/0018.html and the wording proposal at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6009.html (member-only link) has been updated. That proposal is now ready for review by the IG.
(In reply to comments #2 and #3) > 2.2.1.1 Type Definition Hierarchy ... restriction overlaps extension Looks great. > 2.2.1.2 Simple Type Definition > This appears to say mixed=yes => never a simple type def. Yes? I must have been tired, given the backwards paraphrasing of the logic. I was in fact equating "no element children" with "mixed=no", so thanks for the SGML education in the email. The sense in which I meant it was your (c) "For some complex type T, if T.{content type}.{variety} = mixed then T.{content type}.{variety} != simple." and I was simply confirming that this was the correct understanding of the text's intent, not requesting any change. Had my understanding been incorrect, then I would have considered requesting a change. > 2.2.2.1 Element Declaration > "...by triggering identity-constraint definition ·validation·." ok > 2.2.2.2 Element Substitution Group > Actually, this sentence is referring to XML DTDs Yikes! New text does a much better job of naming the alligators in this moat. > 2.2.2.2 Element Substitution Group > New? ok > 2.2.4.2 Type Alternative Maybe I'm now too close, but I had no reading problem with TA instead of TAC. If the inconsistency is ok with the wg, I can certainly live with having pointed it out once so it's clearly a conscious choice. > 3.3.2.1 Common Mapping Rules for Element Declarations - XML Mapping Summary clause 2 Much clearer, thank you. > 3.3.1 The Element Declaration Schema Component Much clearer to me. Since recursion is here to stay, any further editing seems close to/past the point of diminishing returns. > 3.3.4.3 Element Locally Valid (Element) No, no, keep the original text. I was mis-reading it in a different way vs your email; I was mentally inserting *...* "*the namespace of* D is not absent and...", so it was precisely the information you cited that led me to think that any D with a nsuri of [absent] would fail this clause (and hence NEVER be locally valid). > 3.3.5.1 Assessment Outcome (Element) Net: no change required. I think it was a simple case of (a) not remembering the existence of such a property from 1.0, so I concluded it was new, and (b) not seeing anything in 1.1 at this point to introduce such a property, and (c) reading a paper copy then later copying text into comments. (c) is important because it made the hyperlink invisible. Any new reader would still fit into a&&b, potentially into a&&b&&c, but the probability of c seems much lower past the initial drafting phase (i.e. once it's a Rec, most people would use the on-line version for reference and would therefore see the hyperlink). > 3.3.5.2 Validation Failure (Element) error code types So I think the closest pragmatic answer is that schema error codes are (logically at least) of type xs:anyType or maybe (#PCDATA)*. Fair enough, to the (apparently small) degree that such questions are "widely" considered fair. Nothing to see here, move along. Of course, I could (ok, will) also note that "Outcome Tabulations (normative) (§C))" says "...this section tabulates and provides unique names for all the constraints listed...". If it provides -names-, one hopes that said names are in fact QNames vs local-names (since that is a pretty clear Best Practice), and said appendix should clarify which namespace they are in (unless a more general statement earlier is rule to cover this, along with (presumably) all other names defined in this document). > 3.3.5.2 Validation Failure (Element) more than one ... fails to be satisfied - I notice in "[failed identity constraints]" you lost a verb ("that not satisfied"). - Your email starts out by appearing to argue that [schema error code] (to choose a concrete example) contains (in principle) all such codes that result from a given schema validation episode, while the two [failed...] properties in question are defined differently. The proposed Notes seem to very much echo the [schema error code] proposition however (in principle complete, what a given processor makes visible varies), so I'm not seeing any functional difference. From what I'm understanding, there are two (seemingly low-pain) approaches: 1. in the draft Notes, replace "property includes all" with "property includes a subset of" (relying on the fact that every set is a subset of itself, so "all" is still permissible). 2. Remove the two Notes entirely, and let section 2.1 paragraph 1 (processors may not show you everything) govern all of these equally. I'd tend to prefer (2) myself, but can certainly live with either. > 3.3.5.4 Element Validated by Type > Impossible ... actually: the choice ... was removed in 2006. LOL - I have *really good* glasses. Think you need a space, that aside looks fine. from: specifying lighterweight interfaces to : specifying lighter weight interfaces > 3.4.2.3 Mapping Rules for Complex Types with Complex Content ok > 3.4.4.1 Context-determined Type and Context-determined Type Table NEW Typo (; to .) from: legitimate; The ·locally declared type· to : legitimate. The ·locally declared type· > 3.4.4.1 Context-determined Type and Context-determined Type Table > loath to rephrase without mentioning functions The rephrase is clearer to me. This seems like a case where the implementers' need for precision simply outweighs the average readers' need for clarity, so ok. > 3.4.4.1 Context-determined Type and Context-determined Type Table > " This mapping serves as a context-determined type ..." fine. > 3.7.2 XML Representation of Model Group Definition Schema Components looks fine; FYI it did not get flagged as a change. > 3.10.4.2 Wildcard allows Expanded Name > Validation Rule: Wildcard allows Expanded Name - clause 4 I'm agnostic on the addition to 1.5. While I remember the implication truth table from school, this is simply a usage of it I've not had to cope with since Logic classes (in procedural programming, if the antecedent is false you stop but one does not "consider" the truth value of an action, that is an ill-formed question). There is nothing wrong with the spec though (that I can see). > 3.13.4.1 Assertion Satisfied > so they cannot be referred to. I understand the mechanism. The additional note does clarify that Schema is not requiring the XDM processor to treat such references as errors, which is what I was unsure of. The latter part above still sticks in my craw just a bit (technically the issue is not that one cannot "refer" to that content, but that doing so will not return what is intended, which is no doubt how you got to "unsuccessful" in the first place). I would be tempted to truncate the portion above, but can live with it too. > 4 Schemas and Namespaces: Access and Composition ok, ok, call off the African honeybees I'll stop poking the nest. > 4.1 Layer 1: Summary of the Schema-validity Assessment Core - bullet 2 ok so this is just a matter of declarative vs procedural. The spec is intending to be declarative on this matter, and I was thinking procedurally when I posed the question. Fair enough. > 4.2.4 <override> ok (o, to have a Monty Python quote addressing this, but until then: Nee!) > 4.2.5.1 Licensing References to Components Across Namespaces > xhtml ns Always happy to prove I can play the naive reader with the best of them. Since the example below the notes DOES in fact import the html ns, it would seem clearer to be fully pedantic in the example's documentation content from: We do NOT need to import the xhtml namespace into the schema, we only need to declare the namespace prefix. to : This use requires us to define the xhtml namespace prefix, but it does NOT require us to import the xhtml namespace into the schema. from: <xs:element ref="xhtml:p" minOccurs="0"/> to : <xs:element ref="xhtml:p" minOccurs="0"/> <!-- The reference to xhtml:p above requires us to import the xhtml namespace into the schema --> (or similar) > 4.2.5.1 Licensing References to Components Across Namespaces > "...prefixes declared with namespace declarations in the normal way..." I think I was (obtusely) questioning whether a choice of 1.0 Datatypes (implying XML 1.0 and XML Ns 1.0) in a given schema assessment episode (licensed by 1.4) could possibly conflict with the Structures dependency on Namespaces 1.1 (no license to use Ns 1.0 given in section 1.4 of this spec).
Responding to comment #4. John Arwe writes - Your email starts out by appearing to argue that [schema error code] (to choose a concrete example) contains (in principle) all such codes that result from a given schema validation episode, while the two [failed...] properties in question are defined differently. The proposed Notes seem to very much echo the [schema error code] proposition however (in principle complete, what a given processor makes visible varies), so I'm not seeing any functional difference. Correct. I started by saying "they are different" -- as in the status quo I think they are. And then I concluded that they ought not to be different, and that the WG had relapsed into the error of treating infosets as if they were APIs. So you are right that if the changes proposed are accepted, there won't be any functional difference here. I recognize that the problem fixed by the changes in the descriptions of the [failed ...] properties isn't necessarily the problem you were intending to report.
Please refer to the minutes for the resolution.
The changes agreed on the XML Schema WG telcon yesterday have now been integrated into the status quo document at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html The wording proposal mentioned in comment 3 was amended and the proposal was adopted as amended. The minutes of the call will contain detailed accounts of the amendments adopted; a quick summary is: neither of the tentative changes marked not-status-quo in the proposal (in section 1.5 and in Element Locally Valid (Element)) were adopted; the error codes in Appendix C were not declared to be in a namespace (some WG members had backward compatibility concerns, others were not agreed on which namespace they should be placed into); the amendments proposed in comment 4 were adopted (more or less), to wit: -- In 3.3.5.3 for "that not satisfied" read "that are not satisfied" -- In 3.3.5.4 for "lighterweight" read "lighter-weight" -- In 3.3.5.2 remove the two Notes in which the change proposal marks changes (with new text "In principle ...") -- In 3.4.4.1 s/legitimate; The/legitimate. The/ -- In 4.2.5.1 example, make the comment read <!--* The XHTML 'p' element below requires us to define a prefix for the XHTML namespace, but it does NOT require us to import the XHTML namespace into the schema. The use of XHTML (or other) markup here is allowed by the lax wildcard in the schema for schema documents. *--> The XML Schema WG believes that with this issue has now been resolved, and I'm marking it accordingly. John, please let us know if you and SML agree with this resolution of your issue, by adding a comment to the issue record and changing the Status of the issue to Closed. Or, if you do not agree with this resolution, please add a comment explaining why. If you wish to appeal the WG's decision to the Director, then also change the Status of the record to Reopened. If you wish to record your dissent, but do not wish to appeal the decision to the Director, then change the Status of the record to Closed. If we do not hear from you in the next ten days or so, we will assume you agree with the WG decision.
Sorry, forgot one important amendment. The notes a propos the PSVI properties [failed assertions] and [failed identity constraints] were amended. The one for assertions now reads In principle, the value of this property includes all of the Assertions which are not satsfied by this element item; in practice, some processors expose a subset of the items in this value, rather than the full value. For example a processor could choose not to check further assertions after detecting the first failure. Mutatis mutandis, the one for identity constraints reads the same. The last time I looked, I think I had finally gotten the cut/paste errors out, so the note on assertions no longer referred to identity constraints, and vice versa.
(In reply to comment #4) I personally am fine with these updates. I will put it on the SML agenda for 4/27.
On its telecon of 2009-04-27, the SML working group expressed consensus that there were zero objections to Schema deferring resolution of this bug until after the CR drafts are issued.
On its telecon of 2009-08-10, the SML working group expressed consensus that there were zero objections to the resolution proposed. Accordingly, I am closing this bug.