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 10:30:09 -0600
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, XMLSchema-dev <xmlschema-dev@w3.org>
Message-Id: <E0948ED2-93B9-4F23-921F-EDBC3A52F6F3@blackmesatech.com>
To: "Timothy W. Cook" <tim@mlhim.org>

On Mar 21, 2015, at 9:04 AM, Timothy W. Cook wrote:

> 
> 
> On Sat, Mar 21, 2015 at 11:27 AM, C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> wrote:
> I think there are two things you may mean here; one of them is true.
>  
> ​...
>  
>  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.
> 
> 
> ​Thank you. This is where I made my mistake in understanding.  Am I correct in that Schematron will not solve this problem as well? ​

Like XSD assertions, Schematron assertions and reports evaluate
conditions in the document instance, not conditions in the schema.

You can of course use Schematron to define rules which the 
schema document for your schema must obey, and require that any
schema document used in your application satisfy that Schematron
schema.  Or, in the same vein, you can write an XSD schema for
XSD schema documents and require that schema documents
conform to it; your constraint can be expressed more or less well
by an assertion attached to the type of xsd:schema along the lines of:

  each $ct in //xsd:complexType
    [xsd:complexContent/xsd:restriction/@base='myBaseType']
  satisfies
    count($ct//xs:element[@name='id-name']//xs:enumeration) 
    eq count($ct//xs:element[@name='issuer']//xs:enumeration) 
    and
    count($ct//xs:element[@name='issuer']//xs:enumeration) 
    eq count($ct//xs:element[@name='assignor']//xs:enumeration)

Unfortunately, the design of XSD's XML syntax does not make it as easy 
as it should be to express the constraint.  The sketch I've just given
won't work if 'id-name' or the other elements are assigned named types
instead of inline types; it won't work on type R2 if myBaseType is restricted 
by R1 and R1 is restricted by R2; it won't work correctly if the types
of 'my-idname' or the other elements have nested types (e.g. for
attributes) which themselves have enumerations of legal 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.
> 
> 
> ​I can see that this would be the solution from a perspective of the way schemas are commonly used.  

Actually, I'd recommend removing redundancy of the kind described from any
XML application, pretty much whatever schema language is used to define the 
document grammar; my advice is in no way specific to XSD. 

Sometimes, of course, it seems like a good idea (or the least bad idea) to introduce 
redundancies for the sake of some larger good.  And sometimes, perhaps, that
really is a good or least-bad idea.  (Not, in my experience, as often as it proves to
be a snare and a delusion, but your mileage may vary.)

Good luck.

-- 
****************************************************************
* 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 16:30:33 UTC

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