Re: Extension candidates

Michael Kay wrote:

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

  I'd be more inclined to put discussions on the list (at least for
significant changes, and for what is really discussion: questions,
asking for details, ...) while the wiki would be more to put
summaries of useful discussions or just new stuff.

  But that's a community tool, so I'll just follow what people do.

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

  If I am right, those discussions are private, aren't they?

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

  I see.  But in the later case (any sequence type,) what would be the
difference between such a reference and the following variable (that
can be see as a reference to the element 'elem'):

    <xsl:variable name="ref" select=".../elem"/>

  I mean, what use case would benefit from having a sequence with a
non-defined type to serve as reference to a node?  While I could
imagine cases when the reference is a string, I can't when it is not.

> Basically these two requirements come from different use cases, and
> I think they might need different facilities.

  Were there some examples of such use cases on the XQuery WG list?
Is it possible to share them (regarding the W3C's IP policies)?

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

  That's how I see it also.

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

  :-) I first wrote this about parse-html(), then I added the
equivalent for XML, without having think hard enough, it seems...

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

  ex:parse-html(html as xs:string) and ex:doc-html(uri as xs:string),
sounds right to me.

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

  Yes.  So it seems we can maybe just consider ex:parse-html() at
first, and add ex:doc-html() if we want more fine-grained control that
is not possible with ex:parse-html(unparsed-text($uri)).

  Regards,

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