Hi Lenya devs,
I just had a look at the changes to the meta data handling.
It looks straightforward and simple, but I'm not entirely pleased with the detail that the MetaDataManager can handle exactly
1 DublinCore 1 LenyaMetaData 1 CustomMetaData
I understand; I was somewhat hesitant on explicitly creating 3 types as well ... here's the motivation:
- DublinCore is "standard" document meta-data. There is a GUI where the editor can set / change this information. The attributes allowed are precisely those of the Dublin Core specification.
- LenyaMetaData is "for Lenya internal use only". This provides Lenya with an explicit mechanism to store information about a document for its own usage; important at this time is only "resource type".
- CustomMetaData is the mechanism for allowing the storage of arbitrary custom meta-data, requiring no additional configuration
I guess we agree there are different types of meta-data, so the question is how to support them (see below)
> (...)
2) USAGE
MetaDataManager metaMgr = document.getMetaDataManager();
MetaData dublinCore = metaMgr.getMetaData("http://purl.org/dc/elements/1.1/";);
String title = dublinCore.getFirstValue("title");
We could provide some interfaces (like DublinCoreElements) to externalize the
strings (even if this is not considered a best practise by some people):
MetaData dublinCore = metaMgr.getMetaData(DublinCoreElements.NAMESPACE); String title = dublinCore.getFirstValue(DublinCoreElements.TITLE);
If we go that route, I think it should instead be something like
dublinCore = metaMgr.getMetaData(metaMgr.DUBLIN_CORE_KEY);
(whereas the metaMgr.DUBLIN_CORE_KEY could still resolve to some namespace)
So metaMgr would have a list of meta-data sets, where a String constant is the key to accessing the meta-data set one is interested in.
This way we could get rid of pre-defined implementations and allow arbitrary meta data. The restriction is that there's a 1:1 mapping of meta data and namespace URIs.
An even simplier approach would be to allow the storage of custom meta data entries without configuration, i.e. without any restriction:
metaDataManager.setValue(namespaceUri, prefix, key, value);
I do believe that this contract between meta-data user and meta-data manager is less firm and clear than the explicit one. Take the example of Document.getDocumentType(), the implementor of a Document knows from the API that there is a type LenyaMetaData, and knows the name of the attribute with which to read the value she is interested in. If the type didn't exist, she would need to know some other way of getting at the information.
Further, storing the various sorts of meta-data in different namespaces was an implementation decision, which might be changed later; so the user of meta-data should not be exposed to it. In fact I wonder if accessing directly via namespaces might be dangerous: for example Lenya internal meta-data can be overwritten, perhaps even by accident if somebody happens to use the same namespace for a new set of custom meta-data.
Let me try to summarize my opinions :)
1. Explicit types of meta-data sets | 2. Meta-data sets via namespaces
----------------------------------------------------------------
+ better abstraction from | + more flexible approach
storage | (except if storage mechanism
| changes)
+ API/contract is clearer | + n custom sets can be defined,
+ code is probably safer | each in own namespace
- custom meta-data attributes | - contract is based on XML
all live in the same namespace | namespaces, so less clear
| than Java types
I am +1 for option 1, though I could live with option 2 as well.
(you may have guessed it, I am generally biased towards explicit interfaces ... the Java compiler is my friend ;) )
-- Wolfgang
begin:vcard fn:J. Wolfgang Kaltz n:Kaltz;J. Wolfgang email;internet:[EMAIL PROTECTED] tel;work:+49 203 379 2276 tel;fax:+49 203 379 3557 x-mozilla-html:FALSE version:2.1 end:vcard
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
