- 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>
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