RE: [dom-xpath] Competing Proposals Proposal

Dave, thanks for the good comments.

> Caution? 'It should be possible'. either it is or it isn't.

I changed this to "it will be", since this is a goal.

> 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?

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

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

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

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

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

Since this is the "complete" proposal, I think they should remain in, at
least for now.  I do think they should be broken into another interface.

> suggest 'it should follow the extension api being developed....

Done.

> Perhaps this is my problem. Should it read 'provide an interface *for*
(as
> apposed to 'to')? I.e. Someone wanting xpointer functionality can use
this
> interface?

Done.

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

> <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!

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

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

> 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?

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

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.

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

Thanks again for the feedback!

-scott

Received on Wednesday, 10 May 2000 17:46:07 UTC