Hi Matt,
> QNames as met keys sounds like a very interesting proposal, provided we
> still allow for the simplistic met API of simply putting String keys as
> well. So, we shouldn't require that the only mechanism for adding new met
> keys is only via Qnames -- we should support this -- but in addition we
> should also support (for backwards compatibility and simplicity/ease of
> use)
> allowing metadata to be added using String keys as well. So, this should
> still work:
>
> Metadata met = new Metadata();
> met.addMetadata("format", "val1");
> met.addMetadata("format", "val2");
>
> And, this should work:
>
> Metadata met = new Metadata();
> met.addMetadata(new QName("http://purl.org/
> dc/elements/1.0","format","dc"),"val1");
> met.addMetadata(new QName("http://purl.org/
> dc/elements/1.0","format","dc"),"val2");
>
> To support the simple case, we could have the method:
>
> Metadata#addMetadata(String,String)
>
> Simply be a wrapper around
>
> Metadata#addMetadata(QName,String)
>
> like:
>
> public void addMetadata(String key, String val){
> this.addMetadata(new QName(key), val);
> }
>
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.
Uwe
