- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 02 Sep 2008 14:15:02 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6009 Summary: [schema11] unclear passages Product: XML Schema Version: 1.1 only Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Structures: XSD Part 1 AssignedTo: cmsmcq@w3.org ReportedBy: johnarwe@us.ibm.com QAContact: www-xml-schema-comments@w3.org 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"? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 2 September 2008 14:15:36 UTC