[Bug 7059] Forking XPath

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7059





--- Comment #35 from Jonathan Robie <jonathan.robie@redhat.com>  2009-09-14 22:04:41 ---
(In reply to comment #34)

> It has to say "must" otherwise there's no normative conformance criteria, and
> it becomes impossible to determine if it's a statement trying to modify XPath,
> or a statement trying to describe the results of other conformance criteria
> (and failing).

OK. I was trying to simplify the wording, you're right about keeping must, the
rest of this part is editorial. 

> > and also make it clear that it is the path expression, and not the
> > document, that determines whether the node test is testing an element name.
> 
> Surely it's the user agent that determines whether the node test is testing an
> element name?
> 
> I used "the node" because that is what XPath 1.0 section 2.3 Node Tests does
> — it says "A node test that is a QName is true if and only if the type of the
> node [...]" where "the node" has no referent.
> 
> Is there some other term I can use?

You can look at a path expression and tell whether a node test will test
elements or not, you don't need a document to do that. The user agent may apply
a path expression to a document, but you don't need to do so to determine what
the path expression means.

You suggested "when the node test's principle node type is element" - that
works fine.

> > Here's my best shot at this:
> > 
> > [...] namespace URI http://www.w3.org/1999/xhtml (the HTML namespace)
> 
> HTML5 style is to refer to the namespace as "the HTML namespace" with a
> hyperlink to its definition, not to repeat the namespace wherever it occurs.

OK.

> > when the node test occurs in a position where an element or type name is
> > expected
> 
> This doesn't appear to use XPath 1.0 terminology. Do you mean "when the node
> test's principle node type is element"? If so, isn't this redundant with saying
> that the condition only applies when "the node" is an element?

"when the node test's principle node type is element" is fine. You don't have
"the node" until the path expression is applied to a document - and even then,
it might not be applied to a given node. I don't think it's a good idea to
define this in terms of the document to which it is applied, and that's
certainly not how XPath does it.

If you look at the XPath 1.0 spec, you'll see that principal node type is
defined in terms of the expression (with respect to its axes), not the document
that is tested.

> > and the path expression is applied to a document that is an HTML document.
> 
> As far as I can tell, this would miss nodes that are outside of the document
> but whose owner document is an HTML document. It would also fail in the case
> where a node is in a different document than its owner document (e.g. as in an
> XBL shadow tree), though it may be that XPath doesn't support that today
> anyway.

OK - leaving that part out is fine with me, and I like the semantics you
propose better.

> > I would also change the note, since this is no longer such a willful violation:
> 
> It's exactly as much of a willful violation as before. We haven't actually
> changed the implementation requirements at all relative to the text the spec
> had last week, we've just rephrased it in a different way. It's still requiring
> that implementations break XPath 1.0 requirements.
> 
> Please let me know if you still think the spec's current text (quoted aboved)
> is inadequate.

The NOTE is purely editorial, do what you wish with it.

I'll bring this up on the XML Query WG / XSL WG telcon tomorrow morning at
11:00 - 1:00 EST, and I'm pretty sure you would be welcome to join. I'll also
be available on IRC on the #xquery channel during working hours (again EST) if
it's helpful to chat.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 14 September 2009 22:04:52 UTC