[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Defining and operating on types (Was: Re: Wh
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 ;-): <f:makeComparison/> <f:curried> <fun> <f:makeComparison/> </fun> <arity>2</arity> <arg> <some-value/> </arg> </f:curried> > 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 http://www.google.com 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 xsl:choose). BTW, I'll try to write a summary of the type-preserving copies and to post it, as it could maybe interest other people. Regards, --drkm p5.vert.ukl.yahoo.com 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. http://fr.answers.yahoo.com
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|