- From: Bill Han <bill.han@oracle.com>
- Date: Wed, 20 Jul 2005 17:05:12 -0700
- To: Elliotte Harold <elharo@metalab.unc.edu>
- CC: Paul Grosso <pgrosso@arbortext.com>, www-xml-xinclude-comments@w3.org, Jonathan Marsh <jmarsh@microsoft.com>
Elliotte Harold wrote:
> Paul Grosso wrote:
>
>> For colonizedschemename.xml,
>> xpointer="test:xpath(somedata)element(/1/1)", test:xpath(...) is not
>> supported, but element(/1/1) should return p element according to
>> their comments. They don't have any output now.
>
>
> I think the sentence in the test suite that "You should see a p
> element:" was copied from another test case and is not accurate.
> Either that or I originally thought the element scheme should be
> evaluated in this case but was convinced otherwise.
>
> I believe the output of nothing (i.e. fatal error) is correct here. My
> exegesis of this case is that
> xpointer="test:xpath(somedata)element(/1/1)" contains a syntactically
> incorrect XPointer because the test prefix is not mapped to a
> namespace URI by an xmlns XPointer part. This is thus not simply a
> case of an unrecognized scheme. Therefore we don't just fall back to
> the next recognized pointer part.
>
> According to XInclude "An error in the XPointer is a resource error."
> However there's no xi:fallback in this case so the resource error
> becomes fatal. Hence no output.
In the third paragraph of section 3.3 in XPointer Framework spec.,
it says "... is not understood or fails to ...". No matter you have
xi:fallback or not, we can explain that test:xpath(somedata) is not
understood.
test:xpath is a valid qname no matter test prefix is declared or
not. "test:xpath(somedata)element(/1/1)" does follow EBNF syntax defined
by section 3.1.
In my current implementation, I report error too, but I think it
should return what element(/1/1) should return.
How do you think? Paul and Jonathan, what's your opinion?
Thanks,
- Bill
Received on Thursday, 21 July 2005 00:05:26 UTC