W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2006

[Bug 3970] Assertions: Wording of the actual draft

From: <bugzilla@wiggum.w3.org>
Date: Fri, 10 Nov 2006 18:05:02 +0000
CC:
To: www-xml-schema-comments@w3.org
Message-Id: <E1GiakQ-0003Ad-GM@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3970

           Summary: Assertions: Wording of the actual draft
           Product: XML Schema
           Version: 1.1 only
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Structures: XSD Part 1
        AssignedTo: cmsmcq@w3.org
        ReportedBy: fabio@cs.unibo.it
         QAContact: www-xml-schema-comments@w3.org


1) In section 3.4, third bullet from top, "Constraining elements and attributes
to exist, not to exist, or to have specified values, with Assertion (§2.2.4.2)"
are not the words I would use to describe CC. In my mind, the purpose of CC and
of co-constraints in general is to subject the validity (and/or type) of the
defined element/type to the presence, absence or value of other elements and
attributes. Proposal: "constraining elements and attributes to the presence,
absence or value of other elements and attributes".

2) Section 3.4.1, way down (just before 3.4.2): "{assertions} constrain
elements and attributes to exist, not to exist, or to have specified values."
Same as before, with now the additional problem that, given the context and the
sentences immediately before, by the way I read it, it seems to imply that only
direct children (elements and attributes) of the complex type are affected by
assertions. This is not true and could be misleading. Proposal: "{assertions}
constrain the validation of element information items to the successful
verification of (rules about) the presence, absence or value of elements and
attributes in the local subtree".

3) 3.4.2, property mapping, first block: "{assertions} - A sequence whose
members are Assertions drawn from the following sources, in order: 1 The
{assertions} of the {base type definition}. 2 Assertions corresponding to all
the <assert> and <report> element information items among the [children], if
any, in order." The description of derivation of types with assertions is never
discussed as such, but it is described implicitly in two separate pieces. This
is one: it is a bit tiny, and misleading in part. In fact, the order of the
assertions is never relevant. Derived types must simply obey to the sequence of
ALL assertions, in any order, whether they are contained in the base type
definition or in any of the further derivations. Proposal: add somewhere else
(I'll propose) something about derivation of types with assertions, and remove
the words "in order", which are present twice.

4) 2.4.2 farther down, at the end of the table: "Note: If the {base type
definition} is a complex type definition, then the {assertions} always contain
members of the {assertions} of the {base type definition}, no matter which
alternatives are chosen in the XML representation, <simpleContent> or
<complexContent>, <restriction> or <extension>." Correct, but again tells only
half of the story of derivation of types with assertions.

5) 3.4.4 Item #5 "The element information item is ·valid· with respect to each
of the {assertions} as per Assertion Satisfied (§3.12.4)." This is the only
part of the discussion about derivation of types with assertions that is
presented. This is also tiny and not well presented. Suggestion: keep the
wording as it is, and add a note saying something like: "When both the
definition of the base type and the definition of the derived type have
assertions, the overall list of assertions to be evaluated is composed by both
lists. All and each assertion must be evaluated independently. The first
assertion to fail yields a validation error. The order of evaluation is not
relevant and the lists of assertions can have identical terms (which can be
evaluated only once).

6) 3.4.6 Second block: Schema Component Constraint: Derivation Valid
(Extension). No discussion about derivation by extension of types with
assertions is provided. Suggestion: add item "3: The assertions of the complex
type definition are added to the assertions of the base type definitionto form
the full list of assertions to be evaluated."

7) 2.4.6 Third Block:  Schema Component Constraint: Derivation Valid
(Restriction, Complex). Numbering is odd in my copy, but down and well hidden
there is item "7 The {assertions} of the {base type definition} is a prefix of
the {assertions} of the complex type definition itself.". This is unclear to
me. What is a prefix? Why put it in terms of the assertions of the base type
definition instead of the assertions of the complex type definition? Proposal: 
"7: The assertions of the complex type definition are added to the assertions
of the base type definitionto form the full list of assertions to be
evaluated."

3.12.1 The restriction of XPath 2.0 is overly restrictive. I do not understand
especially why no arithmetics is allowed on values, and why predicates can only
refer to attributes on the current element. This excludes things such as
<assert test=".//p[@class='foobar']"/>  -- at least one paragraph of class
foobar must exist
or
<assert test=".//table[count(tr) eq (count(tr[1]/td)+1)]"/> -- I must have one
row for every column, plus one row for table headings.

Both requirements seem quite natural, straightforward, and providing no problem
when implemented in streaming. At least I find.

3.12.1 Also the function list is overly restrictive. I suggest we allow all
those functions for which we have no strong reason for exclusion, rather than
the other way round.

3.12.5 Assertion Information Set Contributions: Possibly we could add which
assertion has failed in case of non valid results?
Received on Friday, 10 November 2006 18:05:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:11 GMT