[exslt] Extension candidates

[Florent Georges]

  Hi,

  Michael and Dimitre have just added new extension candidates on
http://www.fgeorges.org/exslt2-wiki/.  Thank you!  I have a few
questions about them...

> * xx:node-ref() - for any node produce a value, which can be
>   used to obtain this node (node reference)

> * xx:node-from-ref() - navigate to (select) a node from its node
>   reference

  By "value," do you mean "atomic value"?  I am not sure to see
exactly the purpose, would you have a sample use case?

> * xx:nested-sequence() - produce a nested sequence object from
>   one or more components (usually at least one of them a
>   sequence)

  What do you mean by "a nested sequence object"?  I mean, I
understand "nestable sequence," but how can a sequence be nested
by itself?  I guess that's just a vocabulary point, but I'd prefer
to be sure.

> * operator [] for a nested sequence object - evaluate an XPath
>   2.0 predicate on the components of a nested sequence and select
>   the sub-sequence of components for which the predicate is
>   true()

  Interesting.  But I think defining an operator is looking for
trouble when defining extensions, a function providing the same
feature would be better IMHO.

  And maybe this is over specialized yet?  Why not just defining a
function to give the original sequence back from the nested
sequence object?

  I do think this is a very important feature.  Here is what I
have in mind.  The goal is to be able to nest sequences.  Nesting
sequence means that we want to be able to add a particular
sequence to another, and that it won't be atomized (as opposed to
having sequences that wouldn't atomize any other sequences added
to them.)

  I think the most general, simplest translation of those
requirements is into two functions, one to transform a sequence to
"another thing" (I tend to call them "sequence references," but
one can have better wording,) and one to get the sequence back
from this object:

    ex:sequence-ref(seq as item()*) -> item()
    ex:sequence-from-ref(ref as item()) -> item()*

  I think this minimalist API would permit to play with sequence
refs.  If another needs show up with experience, we can always
augment the API.  For instance, the above operator could be
written as:

    ex:sequence-from-ref($ref)[...]

(of course, other considerations, like performance, could need
more specialized functions, but in the first time, maybe those two
simple functions are enough?)

> * xx:parse-html() - as above, for a string containing lexical
>   HTML, return the tree representation as a node

  Funny, I wrote such an extension for Saxon 9, using Tag Soup,
this afternoon...  I wrote something similar to what it is
described above, but I wondered if it could take a URI also,
instead of a string with the content.  So I hesitate between the
following functions:

    ex:parse-xml-string(xml as xs:string) -> document-node()
    ex:parse-xml-uri(uri as xs:string) -> document-node()
    ex:parse-html-string(html as xs:string) -> document-node()
    ex:parse-html-uri(uri as xs:string) -> document-node()

  Or just the following, to keep it simple, because user can
always use unparsed-text():

    ex:parse-xml(xml as xs:string) -> document-node()
    ex:parse-html(html as xs:string) -> document-node()

  I do not have any preference between the names ex:parse() and
ex:parse-xml().

> * xx:xquery() - invoke an XQuery 

  Interesting.  I would add an instruction to import functions
defined in an XQuery module too.

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/