You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/09/15 14:06:10 UTC
[Proposal] Configurable meta data
Hi Lenya devs,
the meta data code is becoming more and more complex.
I'd like to simplify and generalize the meta data handling
using the following approach:
--------
A repository node has just properties.
The metadata concept is separated from the repository layer.
+------+ * +----------+
| Node |------| Property |
+------+ +----------+
There is a MetaData component.
+-------------+
| <interface> |
| MetaData |
+-------------+
^
.
.
.
+----------------------+
| ConfigurableMetaData |
+----------------------+
Basically we need only a single implementation, which is configurable
in the following way (in cocoon.xconf):
<metadata>
<component-instance name="my-metadata"
class="o.a.l...ConfigurableMetaData">
<namespace uri="..."/>
<element name="foo"/>
<element name="bar"/>
...
</component-instance>
<component-instance name="dublin-core-terms"
class="o.a.l...ConfigurableMetaData">
<configuration uri="context://..../dublincore/terms.xml"/>
</component-instance>
...
</metadata>
This way, meta data components can be added by publications, modules
etc. via xpatch files.
If you think that we need more protection of the attributes, we can
offer other implementations which are not configurable but maintain
the attributes in the Java class.
<component-instance name="dublin-core-terms"
class="o.a.l...DublinCoreTerms"/>
--------
In Java, meta data would be accessed as follows:
ServiceSelector selector = manager.lookup(MetaData.ROLE + "Selector");
MetaData dublinCore = selector.select(DublinCoreElements.HINT);
title = dublinCore.getFirstValue(documentNode, DublinCoreElements.TITLE);
For custom meta data:
MetaData myMeta = selector.select("my-metadata");
foo = myMeta.getFirstValue(documentNode, "foo");
The MetaData component would write the meta data to the node's properties,
using the configured namespace URI.
--------
In the sitemap, a MetaDataModule is used:
{ metadata : <meta-data-component> : <element> }
{metadata:dc-elements:title}
WDYT?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Configurable meta data
Posted by Andreas Hartmann <an...@apache.org>.
Felix Röthenbacher wrote:
[...]
>> But maybe this is overkill in the meta data case, as the MetaData
>> are mere
>> data stores with access methods. In this case we could go for the POJO
>> approach, maybe combined with a MetaDataBuilder which is a
>> configurable
>> Avalon component and initializes the actual MetaData objects.
>>
>>
>> If MetaData objects should be components, I see two solutions:
>
>
> What are the advantages to implement the MetaData as Avalon components
> (except configuration)?
Nothing really important, maybe
- logging without passing the logger
- access to the service manager without passing it
> It looks like an overkill, especially when
> it comes to JCR where the MetaData objects will be simple accessors
> to the repository nodes.
Sounds reasonable.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Configurable meta data
Posted by Felix Röthenbacher <fe...@wyona.com>.
Andreas Hartmann wrote:
> Felix Röthenbacher wrote:
>
>> [...]
>
>
> The big problem about methods which return a component is that you can't
> ensure that the component is properly released. It requires one of two
> alternatives:
>
> a) make the MetaData a POJO
>
> -1 as we lose the Avalon config mechanism etc.
>
> b) provide Document.releaseMetaData()
>
> -1 as it is not the Document's concern to provide component handling
> facilites IMO. In most cases, I prefer to see components as services:
>
> component.doSomethingWith(Object object)
>
> instead of
>
> Component service = object.getServiceForMe();
> service.doSomething();
>
> But maybe this is overkill in the meta data case, as the MetaData are
> mere
> data stores with access methods. In this case we could go for the POJO
> approach, maybe combined with a MetaDataBuilder which is a configurable
> Avalon component and initializes the actual MetaData objects.
>
>
> If MetaData objects should be components, I see two solutions:
What are the advantages to implement the MetaData as Avalon components
(except configuration)? It looks like an overkill, especially when
it comes to JCR where the MetaData objects will be simple accessors
to the repository nodes.
- Felix
>
> a) Document acts as a meta data facade:
>
> Document.getFirstValue(String namespace, String key);
> Document.getValues(String namespace, String key);
> ...
>
> b) Use a utility class as a shortcut (this proved to be quite useful):
>
> MetaDataUtil.getFirstValue(Document doc, String namespace, String key);
>
>
>> I would not make a distinction between documents and resources,
>> everything is a document: a picture, an audio file, etc.
>> as long as it documents something :-)
>
>
> OK, that's another "term discussion". Michi, what's your opinion? :)
>
> -- Andreas
>
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Configurable meta data
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Thorsten Scherler schrieb:
> On Thu, 2005-09-15 at 17:24 +0200, Andreas Hartmann wrote:
>>[...]
>>The big problem about methods which return a component is that you can't
>>ensure that the component is properly released. It requires one of two
>>alternatives:
>>
>>a) make the MetaData a POJO
>>
>> -1 as we lose the Avalon config mechanism etc.
>>
>>b) provide Document.releaseMetaData()
>>
>> -1 as it is not the Document's concern to provide component handling
>> facilites IMO. In most cases, I prefer to see components as services:
>>
>> component.doSomethingWith(Object object)
>>
>> instead of
>>
>> Component service = object.getServiceForMe();
>> service.doSomething();
>>
>> But maybe this is overkill in the meta data case, as the MetaData are mere
>> data stores with access methods. In this case we could go for the POJO
>> approach, maybe combined with a MetaDataBuilder which is a configurable
>> Avalon component and initializes the actual MetaData objects.
So wouldn't that simply be the existing MetaDataManager, except that the
data types it would return would now be configured in XML instead of in
Java ?
(I remember this discussion from a while back ...)
>> (...)
>>
>>>I would not make a distinction between documents and resources,
>>>everything is a document: a picture, an audio file, etc.
>>>as long as it documents something :-)
>>
>>OK, that's another "term discussion". Michi, what's your opinion? :)
>>
>>-- Andreas
>
>
> I am not Michi ;-) but documents contain content. They are an
> aggregation of content. Content is every atomic part of a document, like
> pix, audio, video, ...
>
> All this content can provide metadata which e.g. mp3 files and picture
> can store in themselves. So actually everything is *content* and the
> good news is, that Lenya is a content management system. ;-)
+1 to Thorsten's view
See also http://wiki.apache.org/lenya/ProposalContentModel
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Configurable meta data
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-09-15 at 17:24 +0200, Andreas Hartmann wrote:
> Felix Röthenbacher wrote:
>
> [...]
>
> >> I agree.
> >> So that would read
> >>
> >> MetaData dublinCore = selector.select(DublinCoreElements.HINT);
> >> title = dublinCore.getFirstValue(document, DublinCoreElements.TITLE);
> >
> > No, I meant
> >
> > Document doc = getDocumentFromSomewhere();
> > MetaData dc = doc.getMetaData(DublinCoreElements.HINT);
> >
> > doc.getMetaData uses a factory to get the meta data
> > (the factory may use a selector).
> > DublinCoreElements.HINT may be the unique namespace
> > of this meta data component.
>
> The big problem about methods which return a component is that you can't
> ensure that the component is properly released. It requires one of two
> alternatives:
>
> a) make the MetaData a POJO
>
> -1 as we lose the Avalon config mechanism etc.
>
> b) provide Document.releaseMetaData()
>
> -1 as it is not the Document's concern to provide component handling
> facilites IMO. In most cases, I prefer to see components as services:
>
> component.doSomethingWith(Object object)
>
> instead of
>
> Component service = object.getServiceForMe();
> service.doSomething();
>
> But maybe this is overkill in the meta data case, as the MetaData are mere
> data stores with access methods. In this case we could go for the POJO
> approach, maybe combined with a MetaDataBuilder which is a configurable
> Avalon component and initializes the actual MetaData objects.
>
>
> If MetaData objects should be components, I see two solutions:
>
> a) Document acts as a meta data facade:
>
> Document.getFirstValue(String namespace, String key);
> Document.getValues(String namespace, String key);
> ...
>
> b) Use a utility class as a shortcut (this proved to be quite useful):
>
> MetaDataUtil.getFirstValue(Document doc, String namespace, String key);
>
>
> > I would not make a distinction between documents and resources,
> > everything is a document: a picture, an audio file, etc.
> > as long as it documents something :-)
>
> OK, that's another "term discussion". Michi, what's your opinion? :)
>
> -- Andreas
I am not Michi ;-) but documents contain content. They are an
aggregation of content. Content is every atomic part of a document, like
pix, audio, video, ...
All this content can provide metadata which e.g. mp3 files and picture
can store in themselves. So actually everything is *content* and the
good news is, that Lenya is a content management system. ;-)
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Configurable meta data
Posted by Andreas Hartmann <an...@apache.org>.
Felix Röthenbacher wrote:
[...]
>> I agree.
>> So that would read
>>
>> MetaData dublinCore = selector.select(DublinCoreElements.HINT);
>> title = dublinCore.getFirstValue(document, DublinCoreElements.TITLE);
>
> No, I meant
>
> Document doc = getDocumentFromSomewhere();
> MetaData dc = doc.getMetaData(DublinCoreElements.HINT);
>
> doc.getMetaData uses a factory to get the meta data
> (the factory may use a selector).
> DublinCoreElements.HINT may be the unique namespace
> of this meta data component.
The big problem about methods which return a component is that you can't
ensure that the component is properly released. It requires one of two
alternatives:
a) make the MetaData a POJO
-1 as we lose the Avalon config mechanism etc.
b) provide Document.releaseMetaData()
-1 as it is not the Document's concern to provide component handling
facilites IMO. In most cases, I prefer to see components as services:
component.doSomethingWith(Object object)
instead of
Component service = object.getServiceForMe();
service.doSomething();
But maybe this is overkill in the meta data case, as the MetaData are mere
data stores with access methods. In this case we could go for the POJO
approach, maybe combined with a MetaDataBuilder which is a configurable
Avalon component and initializes the actual MetaData objects.
If MetaData objects should be components, I see two solutions:
a) Document acts as a meta data facade:
Document.getFirstValue(String namespace, String key);
Document.getValues(String namespace, String key);
...
b) Use a utility class as a shortcut (this proved to be quite useful):
MetaDataUtil.getFirstValue(Document doc, String namespace, String key);
> I would not make a distinction between documents and resources,
> everything is a document: a picture, an audio file, etc.
> as long as it documents something :-)
OK, that's another "term discussion". Michi, what's your opinion? :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Configurable meta data
Posted by Felix Röthenbacher <fe...@wyona.com>.
Andreas Hartmann wrote:
> Felix Röthenbacher wrote:
>
> [...]
>
>>> MetaData dublinCore = selector.select(DublinCoreElements.HINT);
>>> title = dublinCore.getFirstValue(documentNode,
>>> DublinCoreElements.TITLE);
>>
>>
>>
>> -1 because meta data are tightly bound to documents so I would prefer to
>> access the meta data of a document through the document itself.
>
>
>
> I agree.
> So that would read
>
> MetaData dublinCore = selector.select(DublinCoreElements.HINT);
> title = dublinCore.getFirstValue(document, DublinCoreElements.TITLE);
>
No, I meant
Document doc = getDocumentFromSomewhere();
MetaData dc = doc.getMetaData(DublinCoreElements.HINT);
doc.getMetaData uses a factory to get the meta data
(the factory may use a selector).
DublinCoreElements.HINT may be the unique namespace
of this meta data component.
I would not make a distinction between documents and resources,
everything is a document: a picture, an audio file, etc.
as long as it documents something :-)
>
> Although I'd extend it to
>
> title = dublinCore.getFirstValue(resource, DublinCoreElements.TITLE);
>
> where resource is a generalization of documents and assets
> (we could stick to the MetaDataOwner interface).
>
>
> -- Andreas
>
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Configurable meta data
Posted by Andreas Hartmann <an...@apache.org>.
Felix Röthenbacher wrote:
[...]
>> MetaData dublinCore = selector.select(DublinCoreElements.HINT);
>> title = dublinCore.getFirstValue(documentNode,
>> DublinCoreElements.TITLE);
>
>
> -1 because meta data are tightly bound to documents so I would prefer to
> access the meta data of a document through the document itself.
I agree.
So that would read
MetaData dublinCore = selector.select(DublinCoreElements.HINT);
title = dublinCore.getFirstValue(document, DublinCoreElements.TITLE);
Although I'd extend it to
title = dublinCore.getFirstValue(resource, DublinCoreElements.TITLE);
where resource is a generalization of documents and assets
(we could stick to the MetaDataOwner interface).
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Configurable meta data
Posted by Felix Röthenbacher <fe...@wyona.com>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> the meta data code is becoming more and more complex.
> I'd like to simplify and generalize the meta data handling
> using the following approach:
>
> --------
>
> A repository node has just properties.
> The metadata concept is separated from the repository layer.
>
> +------+ * +----------+
> | Node |------| Property |
> +------+ +----------+
>
Ok. An abstract layer for the meta data makes sense.
>
> There is a MetaData component.
>
> +-------------+
> | <interface> |
> | MetaData |
> +-------------+
> ^
> .
> .
> .
> +----------------------+
> | ConfigurableMetaData |
> +----------------------+
>
>
> Basically we need only a single implementation, which is configurable
> in the following way (in cocoon.xconf):
>
>
> <metadata>
>
> <component-instance name="my-metadata"
> class="o.a.l...ConfigurableMetaData">
> <namespace uri="..."/>
> <element name="foo"/>
> <element name="bar"/>
> ...
> </component-instance>
>
> <component-instance name="dublin-core-terms"
> class="o.a.l...ConfigurableMetaData">
> <configuration uri="context://..../dublincore/terms.xml"/>
> </component-instance>
>
> ...
>
> </metadata>
>
>
> This way, meta data components can be added by publications, modules
> etc. via xpatch files.
-1 for a generic meta data approach as there might also be some
system meta data which needs more protection (see below).
>
> If you think that we need more protection of the attributes, we can
> offer other implementations which are not configurable but maintain
> the attributes in the Java class.
>
>
> <component-instance name="dublin-core-terms"
> class="o.a.l...DublinCoreTerms"/>
>
+1 with different namespaces. E.g.
http://apache.org/lenya/metadata/dublincore/1.0
The namespace is hidden by the meta data component.
>
> --------
>
> In Java, meta data would be accessed as follows:
>
> ServiceSelector selector = manager.lookup(MetaData.ROLE + "Selector");
>
> MetaData dublinCore = selector.select(DublinCoreElements.HINT);
> title = dublinCore.getFirstValue(documentNode, DublinCoreElements.TITLE);
-1 because meta data are tightly bound to documents so I would prefer to
access the meta data of a document through the document itself.
>
> For custom meta data:
>
> MetaData myMeta = selector.select("my-metadata");
> foo = myMeta.getFirstValue(documentNode, "foo");
>
>
> The MetaData component would write the meta data to the node's properties,
> using the configured namespace URI.
>
> --------
>
> In the sitemap, a MetaDataModule is used:
>
> { metadata : <meta-data-component> : <element> }
>
> {metadata:dc-elements:title}
>
+1
>
>
> WDYT?
>
> -- Andreas
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org