RE: [dom-xpath] Competing Proposals Proposal

Now who *has* been busy!

Comments:
<q>The PAX API need not expose the expression language directly to the
interface. Therefore, it should be possible to use PAX to address other
expression languages besides XPath, such as Perl (in a limited fashion), or
perhaps a full-blown XML Query Language.</q>

Caution? 'It should be possible'. either it is or it isn't.
Possible source of confusion for the reader. This is / will be a W3C
rec hence a) needs to be clear, b) Needs to be explicit.

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?

If the latter then the 'language independence ' header needs changing.

<q>The languages that are required are Java, ECMAScript, and IDL.</q>
Whose toes would you be treading on by missing out C++ ?

<q>provide a way of iterating over or otherwise processing that subset.</q>
How to expand this to mean that the iteration is 'non destructive' ?

<q>It must not require all DOM implementers to support this functionality.
</q>
This is stated in the negative. A clear statement might be 'not part of, but
an adjunct to, the dom'. That is positive and says the same. Is it
a) what we want b) what you meant Scott?


<q>It should provide an interface for XSLT Match Patterns. Though they are
XSLT and not XPath, they are very useful.</q>

-1 As it stands. Need to either be explicit (refs to xslt rec?) or cut out.
This group has not mentioned this to date, what use case might support it?
Agreed they are useful, but so are ball bearings :-)

<q>It should provide a way to install XPath extension functions, but it
should not define an XPath extension API (which is being done by the XSLT
WG).</q>
suggest 'it should follow the extension api being developed....

<q>It must provide an interface to XML Pointer Language (XPointer), meaning
that it must provide an interface that returns a Range object.</q>

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?

<q>It must support the setting of variables.</q>
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? Also need to clarify the variable types.

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

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

question from my own ignorance:

<q>
  /**
   * Select a list of nodes from current context.
   */
  NodeIterator selectNodes(String queryString);

  /**
   * Select a single node from the current context.
   */
  Node selectSingleNode(String queryString);
  </q>

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?

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

<q>

  /**
   * Push a string variable onto the variable stack.
   * @param name A QName which may be prefixed.
   * @param value A String value.
   */
  void pushVariable(String name, String value);
  </q>
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.

<q>
  public boolean lessThanOrEqual(XObject obj2);</q>

etc. why are this group a part of the interface please?

Add reference to xpath!

solid start Scott.


Regards, DaveP

Received on Wednesday, 10 May 2000 15:56:46 UTC