On Wed, 19 Sep 2001, bob mcwhirter wrote:
> > I also had to make a decision about how the 'namespace' of unqualified
> > variable and function names should be represented. Both "" and null were
> > used; I'm now using null. I believe there is one spec (can't remember
> > which, could be newest DOM level 3) that states that xmlns:something=""
> > really binds the prefix 'something' to the empty-string. So I think null
> > is safer.
>
> I could be wrong, but I think xmlns:foo="" 'unsets' the prefix 'foo'.
>
> So far, in other places, I've avoided nulls, and am just passing around
> empty-strings for things without defined prefixes.
I got it from the DOM level 3 specs (just found it again) at
http://www.w3.org/TR/2001/WD-DOM-Level-3-Core-20010913/core.html#ID-745549614
It says: (in getAttributeNS)
Per [XML Namespaces], applications must use the value null as the
namespaceURI parameter for methods if they wish to have no
namespace.
But on second reading, that may just apply to attributes.
DOM also writes that each node has an attribute
"namespaceURI of type DOMString, readonly, introduced in DOM Level 2
The namespace URI of this node, or null if it is unspecified."
But that could just be DOM specific.
In jaxen I've seen both "" and null used. BTW xmlns:foo="" is illegal
according to the namespaces spec, only xmlns="" is allowed. But that
probably doesn't stop parsers from handling xmlns:foo="" in an undefined
way.
>
> > However I plan to do that after the release, I'd like write a
> > proposal and implement a way to call existing java functions from xpath in
> > jaxen; there are some pretty useful ones like
> > java.net.URLEncoder.encode(String). But I'd like to make it as similar
> > to/compatible with the way this is done in other java-written xpath
>implementations.
>
> Some flavor of introspector-based catch-all function?
Indeed.
Something like xalan uses; you bind a prefix to to an URL with the 'java:'
protocol, like xmlns:java="java:" or xmlns:jlang="java:java.lang", and
then you can call xpath functions like 'java:java.net.URLEncoder(@title)'
or 'jlang:String.toUpperCase(buyer/name/lastname)'
I don't know yet how to handle other kinds of java classes than strings;
since each class may also be recognized by a Navigator as an element
or attribute etc., there may be some resulting weirdness were functions
behave differently depending on the navigator.
You couldn't do much with a non-xpath type of object, except pass it to a
java function again, or store it in a variable. In principle, xpath allows
other types than the standards types to be used.
- Erwin
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
