RE:[XPath] 2.5.4.4 Schema Element Test

Thanks for your reply,Michael.

I wanted to just confirm about my understanding.
I could understand your explanation.

So, we need to add nillable="true" the declaration of xbrli:item in base,
when our function's argument is xbrli:item.

Thanks
Atsushi Ohtake
Hitachi, Ltd.

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