W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2005

RE: [XPath] 2.5.4.4 Schema Element Test

From: Michael Kay <mhk@mhk.me.uk>
Date: Sun, 10 Jul 2005 22:47:22 +0100
To: <a.ohtake@itg.hitachi.co.jp>, <public-qt-comments@w3.org>
Message-ID: <E1Drje9-0003oc-LT@maggie.w3.org>

Many thanks for raising this very interesting question.

I think that the specification states unambiguously what happens. xbrli:item
is not nillable, therefore an element that specifies xsi:nil="true" (that
is, an element whose nilled property is true) does not match the
SequenceType schema-element(xbrli:item), even though it is a valid instance
of an element in the substitution group of xbrli:item.

I think this is also what the working group intended. The intent is to allow
type inferences to be made statically. In your example xbrli:item has type
xs:anyType, which doesn't allow very much to be inferred about the contents
of the elements, but in the general case, the content model for xbrli:item
might include a mandatory child element itemCode, and the type inferencer
can then conclude that $item/itemCode selects exactly one element, without
having to take into account the possibility that the element might specify
xsi:nil="true" and thus contain no itemCode child.

In fact the working group held a discussion quite recently about rule 3 in
section 2.5.4.4, which in the current published draft is worded:

"Either the nilled property of the candidate node is false, or the element
declaration for ElementName in the in-scope element declarations is
nillable."

This allows the three possibilities (nilled, nillable), (not nilled,
nillable), (not nilled, not nillable), and disallows the fourth (nilled, not
nillable). At first sight it appears that the fourth possibility cannot
arise: how can a node be nilled if the element declaration says it is not
nillable? The answer is that it can arise precisely in the case that you
outline.

In the most recent internal draft we have reworded this rule to read:

"If the element declaration for ElementName in the in-scope element
declarations is not nillable, then the nilled property of the candidate node
is false."

We hoped this reformulation might be clearer, though it is in fact
equivalent.

So I think your reading of the specification is correct, and the
specification was written that way by conscious design.

This is a personal response: if you want an official response from the
working group, please indicate this in your reply (we're outside the
official last call comment period, so the WG will only take it up if it
feels that a serious issue is raised).

Michael Kay
Saxonica Limited


> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of 
> a.ohtake@itg.hitachi.co.jp
> Sent: 08 July 2005 06:16
> To: public-qt-comments@w3.org
> Subject: [XPath] 2.5.4.4 Schema Element Test
> 
> Hello.
> 
> I'm Atsushi Ohtake from Hitachi, Ltd. in Japan.
> I have a question about 2.5.4.4 Schema Element Test of 
> XPath2.0 specification.
> 
> Is below case an "Schema Element Test" error or not ?
> 
> The base schema.
> <element name="item" type="anyType" abstract="true">
> 
> The exended schema from base. "xbrli" is namesapce prefix for 
> item in base.
> <element name="myNillableElement" 
> substitutionGroup="xbrli:item" nillable="true">
> 
> and candidate node is 
> <myNillableElement xsi:nil="true" />
> 
> And a function( use namespace prefix is xfi ) is
> xfi:somefunction($item as schema-element(xbrli:item)) as 
> element(xbrli:item)
> 
> My issue point is below.
> The function of xfi:somefunction only knows the element 
> declaration "xbrli:item" as argument.
> This element declaration "xbrli:item" has a default value of 
> nillable="false".
> So, XPath Processor test the consistensy between "xbrli:item" 
> and "myNillableElement" of actually candidate node ,acording 
> to 2.5.4.4 Schema Element Test.
> 
> So, this is the point.
> If the declaration of somefunction's argument may be different,
> xfi:somefunction($item as 
> schema-element(my:myNillableElement)) as element(xbrli:item)
> This case is good by testing the consistensy between 
> "my:myNillableElement" and "myNillableElement".
> ("my" is namespace prefix for myNillableElement)
> 
> But, we need to declare the argument "$item as 
> schema-element(xbrli:item)" for general use.
> Does we need to change declaration of "xbrli:item" in  the 
> base schema?
> Or
> Is my understanding of "2.5.4.4 Schema Element Test" missread ?
> 
> Regards,
> Atsushi Ohtake
> Hitachi, Ltd.
> 
Received on Sunday, 10 July 2005 21:47:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:25 UTC