RE: [dom-xpath] Competing Proposals Proposal

     They're certainly needed for XSLT.  For XPath, they are needed
     anytime you
     want to paramaterize the expression.  Yes, you could do selectNode
     ("path/to/node[@attr="+java-variable+"]"), but, besides being
     rather ugly,
     that doesn't really work with the Expression object, since it's
     pre-compiled.

Got it The variable-less environment uses

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

Now I definately want to dump variables from the requirement.
Told you it was a kludge :-)

============================

xslt 5.2 <q>The syntax for patterns is a subset of the syntax for
expressions. In particular, location paths that meet certain restrictions
can be used as patterns. </q>

You talked about using 'match patterns' as apposed to xpath paths (location
paths?). Hence the implication is that you are looking for something 'less
than'
xpath?
xslt does not contain the phrase 'match pattern', only pattern.
5.3 says A template rule is specified with the xsl:template element. The
match attribute is a Pattern that identifies the source node or nodes to
which the rule applies.

I'm almost with you on this one, intuitively.
I still want to understand the restrictions mentioned above.

Regards, DaveP

One more. What document (information?) model are we assuming?
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?
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?
Use of an info set model would have one advantage.
This would permit the xpath dream as well,
character access beyond xpointer?

DaveP

Received on Friday, 12 May 2000 10:00:06 UTC