Re: [xsl] Defining and operating on types (Was: Re: [xsl] Why no namespace node KindTest?)

Subject: Re: [xsl] Defining and operating on types (Was: Re: [xsl] Why no namespace node KindTest?)
From: Florent Georges <darkman_spam@xxxxxxxx>
Date: Sun, 27 Aug 2006 19:48:43 +0200 (CEST)
Dimitre Novatchev wrote:

  Hi Dimitre

> > >     $item intersect $item/../namespace::*

> > Only works for a namespace node that has a parent.

> Parentless nodes are strange beasts -- the namespace
> parentless node the strangest among them.

  Mmh.  Parentless nodes sound not so strange to me.  I'm
perfectly ok with parentless nodes like the following ;-):



> I'd call a parentless namespace node "candidate namespace
> instance" because there are no nodes in this namespace. In
> a sense it is not yet "fully produced", not "born".

  I'm not sure to understand.  Don't forget namespace nodes
don't represent namespaces themself (whatever "namespace
themself" could mean), but namespace declarations.  That is,
bindings between prefixes and namespace URIs.

  Namespaces have no "concrete existence" as elements could
have.  It is just a convenient way to have long names in
XML, whose the lexical representation remains short.  All
this in the hope the names will not clash.  The use of URIs
with the concept of authority helps here, but in a
collaborative way; I can define a schema for the namespace if I want.

  It sounds logical to me that namespace nodes can be
parentless.  If a part of the program computes some nodes,
that will be added to a tree in an other part of the
program, and if this sub-tree rely on a particular prefix to
be bound to a particular URIs, it seems logical to return a
namespace node along the other nodes (if it can't be added
directly to the computed nodes).

  Actually, while writing this, I feel parentless namespace
nodes could be the only one that we could be manipulate.  To
summarize the problem:

    The implementors found difficult to implement
    efficiently namespace nodes.  As they have all a
    different parent, and because their identity, maybe it
    is difficult to avoid to have actually an object for
    each namespace node.

    So the WG try to avoid accessing namespace nodes by
    marking the namespace axis as deprecated.  Fine.  But
    they don't have neither a KindTest for such nodes.  So
    there are two possibilities for an hosting language:

    As XQuery, it is not possible to create namespace nodes.
    In the addition to can not access namespace nodes from
    other nodes, you'll nevr get a namespace node "in hand".
    But how to add a binding to a tree?

    Or as XSLT, it is possible to create new namespace nodes.
    If the namespace axis is not implemented, we can still
    get parentless namespace nodes.  And only parentless.
    Because once attached to a tree they are copied, and we
    can't retrieve them without the namespace axis.

    So at a first glance, it seems that the situation where
    1/ we don't have namespace axis, 2/ we have the ability
    to create namespace nodes and 3/ there is a namespace
    node KindTest would be ideal.

  Did I miss something?

> However, it's still a pity we cannot specify its type when
> passing such a node to a function. If this function needs
> to determine the type of the parentless namespace node,
> then it must do something like this:

> >    if ( $item instance of node()
> >           and not($item instance of attribute()
> >                     or $item instance of comment()
> >                     or $item instance of document-node()
> >                     or $item instance of element()
> >                     or $item instance of processing-instruction()
> >                     or $item instance of text() ) ) ...

> but even this code may become incorrect in the future,
> should a new Spec define a new node-type for which there's
> also no type-test.

  Yes, I totally agree.

> In the case of a namespace node, FXSL can provide a
> wrapper around the <xsl:namespace> instruction and thus an

>    f:namespace()

> Of course, as of today, this defines only the type of the
> FXSL constructor for a namespace, not the namespace type
> itself.

  Yes.  It could be a usefull way to achive this goal, but
restricted to FXSL.  And I still don't understand why there
is no KindTest for namespace nodes, even if the namespace
axis is deprecated (and I understand why).

> On a similar topic, recently Florent Georges working on
> FXSL provided a way to copy items having user-defined
> types and to preserve their types during this copying.

> While this is an excellent and useful result, this still
> doesn't allow a generically-typed higher-order-function to
> deduct the type of its user-defined-typed argument -- only
> to do type-preserving operations on it.

  Yes.  But I think here it is a totally different debate.
Types are not first class objects in XSLT.  And I hardly see
how one can hope doing interesting complex things with types
without a preprocessing phase that constructs a global
(parentless :-p) dictionnary graph of the types from a
schema (maybe even with additional informations), in the
goal to have a usable representation of the types.

> Also, Florent's technique could not be applied for
> user-defined types derived from xsl-schema basic simple
> types.

  More precisely, it can't be applied in a generic way to
atomic values.  For the builtin types, it is not a problem.
An xsl:choose, while a little bit ugly, does the work.  But
for user-defined (simple) types, a preprocessing phase on
the schema would be needed (at least to add cases to the

  BTW, I'll try to write a summary of the type-preserving
copies and to post it, as it could maybe interest other



 uncompressed/chunked Fri Aug 25 11:13:44 GMT 2006 
Dicouvrez un nouveau moyen de poser toutes vos questions quelque soit le sujet ! 
Yahoo! Questions/Riponses pour partager vos connaissances, vos opinions et vos expiriences. 

Current Thread