handling namespaces in advance Re: [xsl] namespace required in transform

Subject: handling namespaces in advance Re: [xsl] namespace required in transform
From: "James Fuller" <james.fuller@xxxxxxxxxx>
Date: Sat, 20 Jul 2002 11:05:39 +0100
----- Original Message -----
From: <midnite@xxxxxxxxxxxxx>
> This goes away if I add the namespace to the transform.  However, I am
going to be dealing with multiple xml files, and I won't be able to
> know in advance what all the namespaces are.  How can I handle this?

Karen has reminded me of this old chestnut.

I've been encountering this situation more and more, if not for the pure
fact that xml is now being used in more projects.

for example

xml
----------------------------------------------------------------------------
<?xml version="1.0" ?>
<test:test>
</test:test>

xsl
----------------------------------------------------------------------------
-
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns:test="http://www.test.org";
>

<xsl:template match="/">
</xsl:template>

</xsl:stylesheet>


rightly throws an error.

some scenarios and justifications

- many people are providing 'sorta' xml, instead of text delimited files,
possibly not declaring a valid namespace, though using namespace prefixes
(e.g. <test:test></test:test> ). If we are catering for text situations ala
http://www.w3.org/TR/xslt20/#unparsed-text  then why not deal with near-xml
situations. All right, many of you will say, why not have valid xml.....hehe
I agree, but i'll take nearly xml over unparsed-text. This also eases some
of the integration and migration issues.

- in situations where we are dealing with streaming xml , think possibly
SOAP, there may be short/intermittant/long periods of time, where we are
handling namespace prefixed xml, without having a namespace declaration. Is
it unlikely that a large streaming xml document, such as;

<test:test xmlns:test="urn:sometest">

<amillionelements></amillionelements>

</test:test>

would have strategies for optimizing network transport, in the event of
connection failure, where we may decide, to pick up where we left off,
instead of initiating the sending of the entire file again ? We could
specify that at the very least we pick up with a namespace definition. True
there is an issue that we currently do not have reliable transport solved,
but think of a process that is happening inside a simple machine and it
fails or crashes, resets and continues doing whatever it was doing, picking
up where it left off, .....are we not making the whole system a lot more
brittle by saying you need to have your original namespace decl or we ain't
doing anything with you, or we are restarting this whole process.

- there are issues with encryption/decryption that we may find a snippet of
xml, denuded of its namespace declaration.....though possibly using
namespaced prefixes.

I think that we are going to find, in actual practice, that eventually we
will have a load of requirements for namespace handling functions, and what
better place to put those functions then within XSLT ?

currently, in xml namespace spec,  a default namespace can be set to set to
an empty string
http://www.w3.org/TR/REC-xml-names/#defaulting

why not extend this a little, and say that any undeclared namespaces can be
set to a default unique value ? Possibly will never happen, I admit.

but we can turn things on its head, and have XSLT take in this nearly-xml
and have something equivilent to namespace-alais
(http://www.w3.org/TR/xslt20/#section-Namespace-Aliasing) possibly something
like the following;

<xsl:apply-namespace
    namespace = { uri-reference }
    source-prefix = prefix | "#default"
    result-prefix = prefix | "#default"
    select="the nodeset to be processed"
/>

admittedly we would still have to deal with the 'how' to get this
'nearly-xml' past validation, maybe a new attribute on xsl:stylesheet.

in addition, this might serve as a nice shortcut to mapping namespaces from
one def to another in simple transforms.

just a thought,

ahoy, jim fuller



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


Current Thread