> > > > 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.
Berin, You didn't gave your thoughts about the above. Attribute names are prefixed if they do not belong to the namespace of the current configuration element. And since it's a different namespace, the Namespace object attached to the current element won't help to know the namespace URI of the attribute. I admit few people will have mixed attribute namespaces in confing files, but this is a potential problem. So, should attributes names be kept prefixed, even if it makes it difficult to use them because we cannot get the URI from the prefix ? Or should a restriction on XML configuration documents be enforced, like the one proposed above ? Another restriction could be to forbid attributes from a different namespace than the one of the element they're attached to. Sylvain. -- Sylvain Wallez Anyware Technologies - http://www.anyware-tech.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
