Berin Loritsch a écrit : > > 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.
Neither do I, so maybe a solution is to have an additional constraint on XML configuration documents : local attribute names must be unique, even if their namespaces are different. This isn't really restrictive and can easily be checked by SAXConfigurationHandler. We could then use local names for attributes also. > 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. Mmmh... IMO, null and "" have different meanings : - null means no prefix is associated with the Configuration object and the serializer must determine the actual prefix, either by checking already declared prefixes (NamespaceSupport makes this easy) or by generating a new prefix. - "" means the namespace is the default one like in <foo xmlns="foo-namespace"/> and is a valid value for the prefix. -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
