avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Problems with Configuration and namespaces.
Date Mon, 29 Oct 2001 15:15:35 GMT
Sylvain Wallez wrote:
> 
> 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 ;)

I figured that out after I sent the message.  Doh!


> > > 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
> implementation...

I don't want that.

I displayed that as a way to demonstrate that it is useful to have the
prefix as well.  Again, Configuration should not support every feature
of XML.

> > > 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
> hint.

When I applied the change, the name of the configuration element did not
have the prefix information in it.  That is as it should be.

> > > 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.

The current implementation does not return null, but an empty string.  That way
we avoid NPE all over the place--and can simplify if/then/else statements.

> 
> --
> 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>


-- 

"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin

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


Mime
View raw message