RE: [dom-xpath] Competing Proposals Proposal

dave.pawson@virgin.net wrote:
>  local java string = get from api 'path/to/node/@attr'
>(appropriate syntax :-)
> Then does the compare in the environment which has the ability
> so to do!!!!!
> one extra instruction (high level instruction).

I think you mean 'path/to/node[@attr]'?  'path/to/node[@attr]' may retrieve
4000 element nodes, and or 'path/to/node/@attr' may retrieve 4000 attribute
nodes and then the program would need to loop through them all, checking
the value of 'attr'.  This would be a significant performance problem,
since increasingly XPath implementations will have internal structured
index support to do this much more efficiently.

> xslt does not contain the phrase 'match pattern', only pattern.

Yes, "Pattern" is what I mean by a match pattern.  The relevant section is
http://www.w3.org/TR/xslt#patterns.  Sorry, in the XSL WG we often speak in
terms of 'select' expressions (a subset of the expression syntax) and
'match' patterns.

> I still want to understand the restrictions mentioned above.

The big difference is that "2+2" is not a valid match pattern (but neither
is it a valid select expression).

The "match" pattern grammar is defined at
http://www.w3.org/TR/xslt#NT-Pattern and the "select" expression is defined
at http://www.w3.org/TR/xpath#NT-UnionExpr.  The grammars are pretty hard
to read.  One difference between the two is that "../foo" is not a valid
match pattern (you can't use "." or ".."). You also can't use
VariableReference or FunctionCall at the beginning of a match pattern.  You
can also only use 'child' and 'attribute' axes specifiers in the match
pattern (also '//').  In the predicates full XPath expressions are allowed.
There are good reasons for these restrictions.

> One more. What document (information?) model are we assuming?

Theoretically, the InfoSet.

> The standard xml one, or the xslt one (which has no
> single 'document element' requirement?) Does dom work with
> multiple children of a root element?

I think that the XSLT source tree does indeed require a single 'document
element'.  The non-restriction of multiple document elements refers to the
result tree, and is almost equivelent to the DOM's DocumentFragment.

> This would impact the string value of a node. Will we want a
> returned value of null or an empty string for the string value
> of an empty element?

Hmm... dunno.  Null, I think.

-scott

Received on Friday, 12 May 2000 11:11:21 UTC