xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Vasilik" <eric...@bea.com>
Subject RE: xmlbeans xml security
Date Sat, 03 Jul 2004 17:19:33 GMT
Let me describe the way that the XmlBeans saver deals with namespaces.
I'm not terrible familiar with c14n, but I see a number of differences
which might be difficult to support in the same code.

When XmlBeans saves an instance, it will insert or remove namespace
attributes to preserve the namespace parts of the names of attributes
and elements in the instance.  For example, consider the following
instance fragment:

    <a@no-namespace xmlns="foo_namespace"/>

I use the nomenclature a@no-namesapce to represent an element with local
part "a" and namespace "" (I could have simply written "a", but this is
more specific).  The prefix is unspecified.  This element has a default
namespace attribute declaring "foo_namespace" to be the default

When saving this instance, I cannot write out:

    <a xmlns="foo_namespace"/>

because when parsed back in, a will be in "foo_namespace", instead of
the no-namespace.  Thus, I will not write out this namespace attribute.

Of course, in this case, there may be children which are in
foo_namespace, expecting the default namespace to be mapped as such.
Thus, consider this instance fragment:


Here the element a is in the foo_namespace, but there is no namespace
attribute which declares this namespace.  The way I deal with this is to
declare namespaces as needed.  Thus, I will generate:

    <foo:a xmlns:foo="foo_namespace"/>

If a prefix was specified in the element, I would have used it,
otherwise a prefix is chosen based on the namespace.  Any elements/attrs
in the tree under "a" will be able to use this prefix/namespace mapping,
unless a namespace attribute redefines the namespace to a different

There are options to the saver which will cause the saver to walk the
whole tree, looking for undefined namespaces and declare then at the top
of the document.  This is useful in situations like:

    <root><a*foo/><b@foo/><c@foo/> ... <z@zoo/></root>

Here the default action the saver will take is to define a foo namespace
in a, b, c ... z because the locality of namespace synthesis as a
default.  This option is called the aggressive namespace saver option.

Also of note is the fact that the default behavior of the saver is to
not define the default namespace.  This is so because there may be
QNames in text in the instance which do not use a prefix.  By defining
the default namespace, I might change the meaning of these qnames.
(Defining qnames in the text of an xml document is one of the nastiest
mistakes (in my humble opinion) that was made in xml.)  Of course there
is an option which will enable the saver to define the default namespace
for the first synthetic namespace, when the default namespace is not
otherwise defined.  This is called the use_default_namespace option.

There are other subtleties about the saver, but hopefully this will give
you enough information to evaluate it's congruence with the handling of
namespaces in c14n.

- Eric

-----Original Message-----
From: David Waite [mailto:mass@akuma.org] 
Sent: Friday, July 02, 2004 10:29 PM
To: xmlbeans-dev@xml.apache.org
Subject: Re: xmlbeans xml security

On Jul 2, 2004, at 10:47 PM, Eric Vasilik wrote:

> I would recommend writing the c14n serialization using XmlCursor.  One
> can navigate to the XmlObject for an element and interrogate the
> type, looking for default attributes, for example, and including them 
> in
> the serialization.  This assumes that the instance is valid with 
> respect
> to the schema.  Does c14n require that the instance is schema valid?

Nope. I actually didn't realize they had the attribute DTD-type stuff 
in there at all until this thread started :)

> Also, it seems that the handling of namespaces is significantly
> different for c14n than the current saver handles them.

Could you elaborate?

> You will have total control over the serialization this way and, the
> c14n serialization can be written as a utility on XmlBeans as opposed 
> to
> being in XmlBeans.  The XmlCursor interface is meant to enable high
> performance access to the store.
> Also, there are two other alternatives to using XmlCursor.  In the v2
> codebase, there is a low-level cursor access to the store which you
> could use, but the c14n implementation would then become an internal
> feature of XmlBeans.   This approach would probably yield the highest
> performance c14n implementation.

By internal, do you mean a bundled feature? Or just coupled more 
tightly to a particular release of XMLBeans?

> The other approach would be to use the implementation of the live DOM 
> on
> the v2 store.  Is there an open source implementation of c14n which is
> implemented on top of a DOM?  Could we use it instead of doing it 
> again?

Yes, but the current implementation for using the DOM for C14N within 
XML Security would not be nearly as efficient as doing it ourselves. It 
also has a workaround for Xalan's lack of support for the namespace 
axis, where it copies all namespaces in scope onto every element - it 
modifies the original document in the process of creating the canonical 

-David Waite

- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

View raw message