Michael Kay wrote:
>> I know of the theory (though not all of it) with namespace
>> resolution, but what does it look like for Java? Example, I
>> want my system properties to be bound to the namespace
> Why would you want to do that? As I said before, Saxon assumes Java system
> properties are in the null namespace, and you don't need to do anything
> special in Java to put them there.
I see. Why? Well, firstly because we made up our technical design
documents that way and it stated that the nomenclature of XSLT was to be
followed in the naming of the system properties that were to be used
inside XSLT. This, so to distinguish clearly (from a java perspective)
between 'normal' system properties and those designed for usage in XSLT
stylesheets. We tried and tried, and didn't easily found that the
problem was in the colon (erhm, namespace).
Secondly, because in these same TD documents, it was said to follow the
philosophy of XSLT: having names in a namespace for function, modes,
nodes, attributes, type names, template names, parameter names etc.
(Btw, that brings me to the following. Would it be equally impossible to
set the initial mode to a QName in a non-null namespace? And the initial
template name, same story? It wouldn't be too hard to create special
cases and take them out of their respective namespaces, so to make them
callable from Java/Saxon.)
Finally, in answer to your 'why': just curiosity. Somewhere along the
line it was said that system properties could be set from Java. I never
gave it any thought that namespaces were involved from Java's
perspective and that it would be so hard to set them. But discussing
this in more dept reveals that it is all not so trivial as it looks at
Well, I guess we just make life easier for ourselves and try not to push
this namespaces thing too far. We'll make the names equally well
distinguishable by prefixing them with "xslt.domain.somename".
Thanks again for your thoughts in the matter,
-- Abel Braaksma