W3C home > Mailing lists > Public > xmlschema-dev@w3.org > May 2009

RE: [XML Schema 1.1] The XPath in <assert> cannot "look up" the XML tree, right?

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 14 May 2009 18:44:55 -0400
To: "Michael Kay" <mike@saxonica.com>
Cc: "'Costello, Roger L.'" <costello@mitre.org>, xmlschema-dev@w3.org
Message-ID: <OFE62AF36E.C3A10D05-ON852575B6.007C4A08-852575B6.007CB5EA@lotus.com>
Actually, I would answer Roger by saying "the answer to the question you 
probably meant to ask is 'yes'; the answer to the question you did ask is 

Roger asked:

> The XPath in <assert> cannot "look up" the XML  tree, right?

The correct answer is in detail:

The XPaths in <assert> can look up or down or whatever;  if, however, they 
attempt to go above the element being validated, they will find nothing. 
What I mean is:

* Things like the ancestor axis are not prohibited.  Nothing will crash if 
you try it.  The XPath evaluation is rigged so that the element being 
validated has no parent, but in no other respect are things restricted as 
far as I know.

* The other reason that this difference is nontrivial is that you >can< 
look up if you've already gone down.  So, if you navigate to a descendent, 
then you can indeed look "up the tree" and you will find something. 

So, I think what Roger probably mean to ask is:  "The XPath in <assert> 
cannot "look up" to ancestors of the element being validated, right?"  And 
the answer is "Right in spirit:  you can look, but you won't find 


Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

"Michael Kay" <mike@saxonica.com>
Sent by: xmlschema-dev-request@w3.org
04/29/2009 10:02 AM
        To:     "'Costello, Roger L.'" <costello@mitre.org>, 
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: [XML Schema 1.1] The XPath in <assert> cannot 
"look up" the XML  tree, right?

> I wish to confirm that I correctly understand the 
> specification. I believe it says the XPath in an <assert> 
> cannot "look up" the XML tree. That is, it can't reference a 
> parent, grandparent, etc. Is that correct?

Yes, that's right. The idea is that the validity of an element (or, if you
like, the rules for a type) depend only on the content of that element, 
not on the context where it is used.
> Consider this instance document:
> <Document classification="secret">
>     <Para classification="unclassified">
>           ...
>     </Para>
>     <Para classification="secret">
>           ...
>     </Para>
>     <Para classification="unclassified">
>           ...
>     </Para>
>     <Para classification="secret">
>           ...
>     </Para>
> </Document>
> Here I place an <assert> on the Para element which attempts 
> to reference the (parent) Document element:
> <xs:element name="Para">
>     <xs:complexType>
>         <xs:simpleContent>
>             <xs:extension base="paraType">
>                 <xs:attribute name="classification" 
> type="classificationLevels" use="required"/>
>                 <xs:assert test="if (@classification eq 
> 'top-secret') then ../Document/@classification eq 'top-secret') ... />
>             </xs:extension>
>         </xs:simpleContent>
>     </xs:complexType>
> </xs:element>

This is a rule affecting the validity of the Document, not the validity of
any Para considered in isolation. It needs to go at the Document level.

<xs:complexType name="DocumentType">
    <xs:assert test="if (@classification ne 'top-secret') then
empty(Para[@classification eq 'top-secret']) else true()"/>

If you're in a world where PSVI annotations matter, each Para is valid, 
the Document is invalid.

Michael Kay
Received on Thursday, 14 May 2009 22:43:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:51 UTC