Hi Chris,
> > There is another way to map the string-only variant: QName.valueOf().
> This
> > static method parses the QName in the same way, like XSL-Parameters are
> > given as string to stylesheets. Not-namespaced QNames are generated the
> same
> > way like above, so the DC variant could also be generated this way using
> a
> > string only: QName.valueOf("{http://purl.org/dc/elements/1.0}format";).
> The
> > ns-prefix is uninteresting, because QNames do not need one without a XML
> > parser content (the URI identifies the namespace alone). This is why
> > equals() and hashCode() only use namespace and localName.
>
> The problem with what you are suggesting is that it implies that we know
> (in
> the String only case) that there is an implicit ns of
> "http://purl.org/dc/elements/1.0"; attached to format. In the String only
> case, we aren't always guaranteed this (b/c we still want to support
> arbitrarily defined keys as well.
Yes, but the valueOf-Case would simply generate a QName without namespace,
what would be correctly behaviour.
For the pre-defined constants (e.g. Metadata.CONTENT_TYPE) we could simply
map them to QNames (which makes source codes compatible with the new API,
but not binary compatible), or just redefine the consants as
"{namespace}name", that completely uses the old API (but makes use on
QName.valueOf() in the old code). The latter change would be 100% backwards
compatible, as long as there are no hard-coded string constants in parsers
(which would then appear without namespace).
> I will file a JIRA issue and prepare a patch to upgrade o.a.t.m.Metadata
> to
> use a Map<QName,List<String>> internally and to keep existing API
> compatibility. Then you can let me know if and how it meets your needs.
Fine!
> Also, as an FYI, my name is "Chris", not "Matt".
Sorry, it was in the morning and I was still half-sleeping :-)
Uwe
