[Bug 6009] New: [schema11] unclear passages

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