J. Wolfgang Kaltz wrote:
Andreas Hartmann schrieb:
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.
Yes, but this could also be implemented using the dublin core
meta data configuration file(s) which would be provided by the
Lenya core.
- 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".
See above.
- CustomMetaData is the mechanism for allowing the storage of arbitrary
custom meta-data, requiring no additional configuration
But then you have no safety at all. Sure, the integrator could externalize
the key strings to avoid typos when accessing the meta data, but with
the configuration approach that would be ensured by the system.
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.
Hmm, that's exactly what I wanted to avoid ...
IMO the MetaDataManager should not know anything about existing
meta data types. If the meta data types are hard-wired in the code,
my "maintain backwards compatibility" bells start ringing ...
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.
In the above example - I quote it again -
>> MetaData dublinCore =
>> metaMgr.getMetaData(DublinCoreElements.NAMESPACE);
>> String title = dublinCore.getFirstValue(DublinCoreElements.TITLE);
I don't see a code integrity risk. The API clearly states the options
for accessing DublinCore and LenyaMetaData attributes. And for custom
meta data, the risk is not higher that with the current CustomMetaData
class. IMO it is even safer because the set of possible keys is defined.
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.
OK, changing this would not be possible. But there has to be a mapping
from anything to meta data types. IMO static fields
(DublinCoreElements.NAMESPACE) qualify as good as method names
(metaMgr.getDublinCore()) since both are checked on compile time.
And concerning custom meta data, neither approach can be verified
before runtime.
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.
Namespace clashes could be caught during initialization.
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 ;) )
OK, it looks like both of us stated our opinions :)
Let's hear what the others think ...
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
