Re: attribute namespace "" or null or both
Stefan Haustein <[email protected]>
| Newsgroups | gmane.text.xml.xmlpull.devel |
|---|---|
| Organization | Univ. Dortmund FB 4 LS 8 |
| Message-ID | <[email protected]> |
> ok. so we have that irregardless of namespace processing on or off
> those calls are equivalent:
> getAttributeValue ("", name)
> getAttributeValue (null, name)
> getAttributeValue (NO_NAMESPACE, name) //as NO_NAMESPACE is ""
ok
> i do not think it is needed: attributes can be declared
> (1) in NO_NAMESPACE (i think we should allow both "" and null)
> and no prefix is needed for it. moreover no prefix is even
> allowed (namespace URI "" can only be for to default xmlns and no xmlns:prefix)
> (2) in non-empty namespace.
> if create==false return prefix if namespace is declared or null
> (there is interesting case when namespace has more than one prefix:
> xmlns:prefix1="foo" and xmlns:prefix2="foo" - what is prefix for namespace "foo"?
> if create==true we can always auto generate prefix if needed and declare namespace
The problem I was talking about was that for elements,
it is not required to generate a prefix if the
default namespace matches the desired namespace.
Thus, returning "" without prefix creation would be
sufficient, "" could be considered as "existing" prefix
for elements. No additional prefix declaration is
required for elements. In many cases, all attributes
are in no namespace, so creating an explicit prefix
would not make much sense in that case.
In contrast, the default namespace does not apply
to attributes. Thus, for attributes a prefix
different from "" would be required.
However, this may only be important for using
automatic prefix generation internally, I can
handle this using an additional private method.
On the client side, one could use two getPrefix()
calls to achieve the same functionality.
So let us stick with getPrefix (String namespace, boolean create);
Concerning overlapping prefixes, I think the
serializer should always use the prefix nearer
to the top of the prefix stack.
Best,
Stefan