W3C home > Mailing lists > Public > www-dom-xpath@w3.org > May 2000

RE: [dom-xpath] Competing Proposals Proposal

From: Dave Pawson <dave.pawson@virgin.net>
Date: Thu, 11 May 2000 18:44:30 +0100
To: <www-dom-xpath@w3.org>
Message-ID: <NDBBKDFLFKGBNPJPGKDFIENACDAA.dave.pawson@virgin.net>
Scott:

     > I can't see which way you are looking, 'at' the interface or
     from behind
     > it, when you mention perl / xql. Language neutrality has
     been mentioned,
     > is it that which is being spoken of, or the 'xpath'
     expression language
     > alternative? E.g. this *may* be a means of querying XML
     documents which
     > could be taken forward to become the basis of xql or other
     query forms?

     Not sure I grock this paragraph.  I meant, the API should be
     able to deal
     with expression languages other than XPath.  I changed the header to be
     "Expression Language Independent".  Does this make it more clear?

Personal view. An api is an interface to a black box piece of
code. I always view an api from the outside looking in. Hence
might perl be a 'user' view of the api (i.e. I can write in perl,
using the api), or the black box is implemented in perl / xql.
I found it confusing. Hence I asked which way were you facing when
you made this statement? from within the black box looking out, or
from the outside looking in?

<yuk>Is that more 'grockable'</yuk type="grinning">






     > Whose toes would you be treading on by missing out C++ ?

     I think the DOM group needs to define a C++ interface first.  I only
     included the languages that the DOM defines.
Fine. I was thinking of the politics.

     > How to expand this to mean that the iteration is 'non destructive' ?

     Do you mean that the source tree must not be mutated?  I added
     "The input
     must not be mutated."
I don't understand mutated. The *only* interface I have used didn't
permit me to iterate over the nodelist more than once. I found this
restrictive and didn't want it repeated.

     > This is stated in the negative. A clear statement might be
     'not part of,
     but

     Changed to read "Implementation of PAX should be optional for DOM
     implementors."  I don't think the requirement should read
     whether or not
     PAX is inside or outside of the DOM.  That is a design decision that is
     built from the requirements.

I'm fine with that.


     > -1 As it stands. Need to either be explicit (refs to xslt
     rec?) or cut
     out.

     The "XSLT Match Patterns" was linked to the match pattern
     section of the
     XSLT specification.  Don't understand what you mean by "be explicit".

<q>It should provide an interface for XSLT Match Patterns. Though they are
XSLT and not XPath, they are very useful.</q>
Its a should not a shall. Are we all OK to include XSLT items in what is
supposed to be an xpath focus. Without going to xslt rec I'm unable to
comprehend the implications of this. Hence the -1. Perhaps if someone
explored the ramifications of stating an intent to implement paras
a b c d of xslt then I could understand it. Hence the call to be explicit.


     > This group has not mentioned this to date, what use case
     might support
     it?
     > Agreed they are useful, but so are ball bearings :-)

     I have mentioned it in one of my earlier mails.  I think they are more
     useful to a software program than ball bearings.  The provide
     the ability
     to itterate over a set of nodes, and quickly decide if a given
     node matches
     a given criteria.  A lot better than, checking the name of an element,
     checking to see if it has a certain attribute, etc.

I'll move up to a 0 (neutral) until I understand the implications some more,
withdraw if no one else objects.



     > Again I have a perspective issue. Variables presumably can
     be set in the
     > local environment. Guess we are speaking of variables as per
     XSLT/XPATH.
     > How to clarify? something about 'variables *across* the API'
     or 'as part
     of
     > the api?

     Well, XPath speaks of variable bindings.  XSLT speaks of how
     to bind those
     variables.  From the XPath spec: "The variable bindings consist of a
     mapping from variable names to variable values. The value of a
     variable is
     an object, which can be of any of the types that are possible
     for the value
     of an expression, and may also be of additional types not
     specified here."
     So, the job of the API is to provide for binding of these variables.  I
     changed the text from "It must support the setting of
     variables." to "It
     must support the binding of variables."

     > Also need to clarify the variable types.

     Added "The types of these variables will be return <loc href
     ="http://www.w3.org/TR/xpath#node-sets">Node-sets</loc>, <loc href
     ="http://www.w3.org/TR/xpath#booleans">Booleans</loc>, <loc href
     ="http://www.w3.org/TR/xpath#numbers">Numbers</loc>, and <loc href
     ="http://www.w3.org/TR/xpath#numbers">Strings</loc>, but other variable
     types should be possible, such as a Java Object (which may be
     passed to an
     extension function).".

Proposal then, to be shot down or otherwise. If the variables of the
calling language are not enough, I think we have something wrong.
 I guess I'm thinking
about why variables (constants?) were added to xpath xslt. I can't find
a direct use for them in a (for example) java implementation which already
has variables. whats the implication of ignoring xpath variables 'across'
the interface? can I do 'path/to/node[@attr=java-variable]' 'somehow'
without xpath ish type variables? Beyond me, sorry.



     > <q>without having to re-parse the expression</q> No prior mention of
     > the expressions needing to be parsed.

     Huh?  Expressions always need to be parsed!

Not the point. Within the document there is no requirement statement
that xpath expressions need parsing. Hence if that is not a requirement
then how can there be a requirement to re-parse? Nit picking maybe.
But the document should stand as 'complete'. Suggest add a requirement
to parse xpath paths.

     > No mention of available functions.
     > 'It must support all xpath functions'

     Well, I think that is partly a matter of the implementation.  Added a
     requirement that "The API must support all XPath
     functionality", which is
     different from saying that an implementation must support all of XPath
     functions, i.e. functions are not exposed to the interface.
'Straying' perhaps from xpath? A context includes a define suite of
functions if I remember rightly. Will this be supported or not?

     > If I perform a query I have no knowledge of whether it will return
     > a node or a nodeset. Why not stick to a nodeset which may have
     > a nodelength of 0 to many, as per DSSSL?

     The problem that I have found with selectNodes in the Xalan
     XPath interface
     is that you often only want to find a single node.  A node itterator is
     simply more work.  XSLT contains a xsl:value-of which only
     get's the first
     node... it's the same sort of thing.  This is really from direct user
     experience, I've had more than one user write their own selectNode
     function.
OK, I'll bow to experience. I like those roundy brackets better than
angle ones. I know Scheme is at home with lists of 0, 1 or many elements ;-)


     > Won't most of the functions in 2.1 require a namespace parameter?

     You only need to resolve namespace prefixes in the expression, which is
     covered by setPrefixResolver, right?
I'm unqualified to judge.

     > There appears something intrinsically wrong here. 'Pushing'
     > variables across an interface for use by 'the other side'.
     >
     > Is there nothing more 'elegant' we can come up with?
     >  How / why are they needed? Can they not 'remain' on one
     > side of the api? (Again speaking in ignorance of the technical
     > aspects of any java (or other) interface.

     Hmm... I'm not sure what you mean by "one side of the api", or why you
     think the concept of pushing variables is bad.  Do you mean
     you would like
     your program to get called back when the implementation finds
     a variable
     name?  That seems to me to be much more complicated.

As I note above, I'm uncomfortable with variables of this type in
a variable rich environment. What functionality is lost if variables
are? Or perhaps we could 'parse' them out (i.e. have the parser replace
variables with values prior to passing them 'across' the api? I ask
again why, looking to my note above about why they were introduced into
xpath). If I'm still not clear after this one I'm prepared to drop my
objections. Variables seem like a kludge looking for elegance.
(I'm beginning to think I'm very unclear here ;-)

     Variables in Xalan are implemented on a stack, because we have
     to push and
     pop them all the time to support XSLT.  So it seems to me
     natural and easy
     to specify a stack.  But I'm open to other possibilities, like
     passing in a
     Dictionary object of some kind.

     > <q>
     >   public boolean lessThanOrEqual(XObject obj2);</q>
     >
     > why are this group a part of the interface please?

     This comes from the potential need to compare to result
     objects according
     to the rules of comparison in XPath (see the stuff about equality and
     relational operators in
http://www.w3.org/TR/xpath#section-Expressions).
In particular, the rules about comparing a String, Number, or Boolean to a
Node-set are nasty.  We could probably do without them, but since this is a
proposal for a "complete" API, I thought it good to include them.  If
you're passing XObjects to variables, they may be especially important, as
the XPath implementation may need to use them to do comparison operations.

Fair comment.


> Add reference to xpath!

I was actually trying to be careful about not referencing XPath too much,
since the API is supposed to be "Expression Language Neutral".

Again I'll bow to your reasoning.


Regards, DaveP
Received on Thursday, 11 May 2000 13:45:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:07 UTC