avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Problems with Configuration and namespaces.
Date Mon, 29 Oct 2001 15:08:09 GMT

Berin Loritsch a écrit :
> Sylvain Wallez wrote:
> >
> > Hi all,
> >
> > I've tried to use the new namespace-aware Configurations and encountered
> > serious problems : each Configuration is given the latest namespaces
> > declared whatever its actual namespace is.
> >
> > For example :
> >     <?xml version='1.0'?>
> >     <ns2:config xmlns:ns1='namespace-1' xmlns:ns2='namespace-2'>
> >      <ns1:child name='child-config'>
> >        <foo>value of blah</foo>
> >      </ns1:child>
> >     </ns2:config>
> > leads to all elements being marked as belonging to "ns2" (the latest one
> > declared).
> >
> > So please find attached a patch for both SAXConfigurationHandler and
> > DefaultConfigurationSerializer.
> I would like to apply them, but I need the source to NamespaceSupport.

org.xml.sax.helpers.NamespaceSupport ;)

> > But there's another important issue : configurations are given the
> > prefixed name of the XML element (e.g. "ns2:config" and "ns1:child"). I
> > think this is wrong : namespace prefix is only XML syntactic sugar and
> > doesn't have any semantic meaning (you can give any prefix to a
> > namespace). Having prefixed names obliges either the configuration file
> > to use predefined XML prefixes (we've seen on Cocoon how error prone
> > this can be) or the application to manually strip prefixes when
> > processing the configuration.
> Keep in mind that each prefix:uri combination is unique in XML.
> <root xmlns:ns1="namespace" xmlns:ns2="namespace">
>   <element ns1:foo="bar" ns2:foo="baz"/>
> </root>
> Notice in the above, ns1:foo != ns2:foo.
> They are unique and independent attributes as far as an XML parser is
> concerned, therefore the above markup is legal.  If they were both
> ns1:foo attributes, the above markup would not be legal.

Agree. But in the above example, how would you know what are the URIs
associated to "ns1" and "ns2" when handling the attributes of the
"element" Configuration object ? I'm afraid there is no solution with
the current Configuration interface since attributes aren't represented
as objects that could have an associated URI. And having an Attribute
class would turn Configuration nearly into a lightweight DOM

> > What I propose is that a Configuration object is given the local XML
> > element name (no prefix) and only has the URI as namespace information.
> > The Namespace class could even be removed.
> This is an option.  We do want it to be clear that just because we support
> XML markup, that we do not support every aspect of it.  For example,
> the XML must be Structured--not semi-structured.

Agree. This is also why I suggest prefix to be only a serialization

> > The only use I can see for the prefix is for XML serialization. We could
> > either :
> > - have the serializer auto-generate prefixes (ns1, ns2, etc), possibly
> > with the help of a Map of default prefix/URI mappings,
> > - keep prefixes in Configuration only as a serialization hint. But
> > application code using Configuration objects shouldn't have to worry
> > about it, meaning as above automatic prefix generation for
> > Configurations created by the application.
> The consept behind the Namespace object was to maintain the prefixes that
> the administrator chose, but only use the prefix as a serialization hint.
> Granted that can be accomplished by making the getPrefix() method protected.
> But then you are stuck with the ConfigurationSerializer in the configuration
> package.

It could be public, but clearly identified as being a hint and allowed
to return null.

Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message