W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2015

Re: Xpath result vs. xs:assert result

From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
Date: Sat, 21 Mar 2015 08:27:21 -0600
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, XMLSchema-dev <xmlschema-dev@w3.org>
Message-Id: <C7B4C0A0-FFC9-4BCC-9CCF-7A6ACBA8729A@blackmesatech.com>
To: "Timothy W. Cook" <tim@mlhim.org>

On Mar 21, 2015, at 5:27 AM, Timothy W. Cook wrote:

> 
> 
> On Fri, Mar 20, 2015 at 9:46 PM, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
> 
> On Mar 19, 2015, at 11:15 AM, Timothy W. Cook wrote:
> 
> 
>  
> Assertions are predicates which are required to be true for each instance
> of a type; they are evaluated with the element (or attribute) being validated
> as the current node, not with the declaration of the type as the current
> node.
> 
> 
> ​So, I am incorrect in assuming that a derived by restriction complexType, will have to be valid according to the asserts in the base complexType? ​

I think there are two things you may mean here; one of them is true.

The assertions included with a complex type B will be checked by a validator
for every candidate instance of B, including candidate instances of any type R
derived by restriction from B.  (I call them 'candidate instances' of B and R,
and not 'instances', because an XML element for which the assertions do not
hold is by definition not an instance of B or R.)  So if R is derived from B by
restriction, then it is a condition of validity against type R that all the assertions
associated with B be true, as well as those included in the definition of R
itself.

But the assertions associated with B are evaluated for candidate instances of
B, not for definitions of complex types derived from B.  So the assertions 
included in the definition of complex type B have no effect on the conformance
or schema-validity of the definition of complex type R.  The only assertions
which would be evaluated for the xsd:complexType element which defines
R would be those in the schema for XSD schema documents.  And in the
current version of the XSD schema for XSD schema documents, there are no
assertions.

> 
> ​When the values for those three elements are converted to a UI (through some programmatic process​), only the id-name element might be displayed for user selection. But the instance data will require the other two elements and the application will choose those values based on the index order of the id-name.  This is why is it essential to insure that when the complexType is used as a base for a restricted complexType that the author of that restriction creates the same number of enumerations for each of the three elements. Even if they have duplicate values.  

From your description, it sounds as if the 'issuer' and 'assignor' elements
in the XML document are conveying no information:  the values for each
can be calculated from the value of 'id-name'.  If this is so, then the simplest 
way to address your problem is not to solve it but to dissolve it by 
removing the redundancy from the design.


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com 
* http://cmsmcq.com/mib                 
* http://balisage.net
****************************************************************
Received on Saturday, 21 March 2015 14:27:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:16:08 UTC