[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Content constructors and sequences

Subject: Re: Content constructors and sequences
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Wed, 9 Jan 2002 16:42:52 +0000
prefix ise

>> Possibly - can you think of some examples where you need to access
>> a namespace node given you have access to a QName?)
> does the qname also have the prefix? in xpath 1 name() ise defined
> in terms of finding a namespace node in scope and getting the prefix
> from there...

Officially, according to the XML Schema data types Rec, it doesn't,
but I would imagine that to support user expectations about xs:QNames,
they will do in most applications.

Getting the string value of a xs:QName is always going to be a strange
affair. To get a lexical value ("prefix:local-part") for a xs:QName
you have to have some idea about what namespaces are in scope.

Imagine I create a variable called $foo as follows:

  <xsl:variable xmlns:my="http://www.jenitennison.com/"
                select="QName-from-string('my:qname')" />

And then somewhere else I do:

  cast as xs:string($foo)

then where does the prefix come from? The in-scope namespaces from the
stylesheet? From the context node? What happens if there is no context
node (because we're iterating over a sequence)? What happens if
there's no namespace node in scope on the context node? What happens
if the stylesheet no longer has the relevant namespace in scope?

The only sensible thing (I *think*) is to use the prefix that was used
during construction of the QName and accept the fact that this prefix
might not be associated with any namespace any more, or might be
associated with a completely different namespace, which means you
can't round-trip the xs:QName. I think that's acceptable because if
you wanted to get the namespace-URI out of the QName then you should
never have turned it into a string in the first place! :)

Lots of this would go away if there was a canonical representation for
QNames that didn't involve in-scope namespaces...

>> That would force people to use element node 'holders' for them
>> instead.
> but that means you can construct sequences of anything except
> attributes, which seems a bit odd.

Sequences of anything except parentless attributes, I think. You could
still construct sequences of attributes, as long as they belonged to
some element (which might be documentless). It's the same as the
limitation on the content of RTF variables as it stands (RTF variables
can't directly hold attribute or namespace nodes because document
nodes can't have attribute or namespace nodes).

But I agree it's weird and not very helpful.

>> Third, you could change the data model so that the namespaces
>> accessor on attribute nodes returned a sequence of in-scope
>> namespaces for that attribute. That would be a departure from the
>> XML Infoset, though.
> Yes that occurred to me as well. I suspect that would be the most
> natural thing to do, although you'd still have to adjust the xpath2
> namepsace nodes shared at the document level, I think.

It's really not clear to me where these namespace nodes 'live'. I
imagined that there was a whole bunch of them just floating around in
memory, with element nodes pointing to them as required, rather than
them being associated with a document at any point (they don't even
have a base URI, which says something!).



Jeni Tennison

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.