Re: Extension candidates

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

I wonder if we shouldn't capture the discussion on the wiki itself. Start by
creating a page for discussing each candidate extension, then put the
questions there and let each evolve into a specification.
> 
> > * 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?

There's been a fair bit of discussion of such functions on the XQuery WG
mailing list in the last few weeks. Some people wanted the ref to take a
form of a string or URI so it could be stored in a document. Some wanted
ref() to be synonmous with generate-id(). Some wanted it to be a ref() to
any value (sequence), not necessarily just a node. A big difficulty is the
interaction with garbage collection. There are two conflicting requirements
- the reference should be a string, so you can store it in a document; but
the node should continue to exist so long as the reference exists. Basically
these two requirements come from different use cases, and I think they might
need different facilities.

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

I personally think that if we have a usable x:ref object as an item, then we
can construct a nested sequence as a sequence containing x:ref objects.
> 
> > * 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()

That surely is the same as doc()?

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

Why not call that one ex:html-doc(uri)? 
> 
>   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()
> 
Agreed, ex:html-doc($uri) seems to be just
ex:parse-html(unparsed-text($uri)) - except it might be able to be more
intelligent about media type, encoding, etc.

Michael Kay