new LenyaMetaDataGenerator and new namespace?

Andreas Hartmann wrote:
> Hi Jörn,
> 
> IMO the problem about this schema is that it is not
generic,
> i.e. it is not possible to add custom meta data sets
without
> changing the schema. 

that's a feature.

> Additionally, if you convert meta data
> to elements, you have to make assumptions, e.g.
regarding the
> internal storage of workflow versions. This is a
concern of
> the workflow engine, the meta data component may only
read or
> write the meta data but not try to parse or understand
them.
> 
> 
> I'd prefer something like this:
> 
> <meta-data xmlns="http://apache.org/lenya/.
..">
> 
>   <elements namespace="...">
>     <element name="foo">
>       <value>hello</value>
>       <value>world</value>
>     </element>
>     ...
>   </elements>
> 
>   ...
> 
> </meta-data>
> 
> 
> I understand that this is not as good as your
suggestion when
> it comes to validation, but IMO we have to use a really
extensible
> and generic format to render meta data as XML.

depends on what you want. i intended the grammar to be fixed
and
non-extensible wrt core metadata, so that it really hurts to
introduce
changes 
moreover, the more detailed and less flexible a grammar is,
the better
it is for documentation.

ultimately, the most flexible solution is

<define
name="everythingandthekitchensink">
<element>
	<nsName/>
	<zeroOrMore>
		<attribute>
			<anyName/>
			<optional>
				<text/>
			</optional>
		</attribute>
	</zeroOrMore>
	<interleave>
		<optional>
			<text/>
		</optional>
		<optional>
			<ref
name="everythingandthekitchensink"/>
		</optional>
	</interleave>
</element>
</define>
	
<start>
	<ref name="everythingandthekitchensink"/>
</start>

;)

SoC at its very best, and totally useless for both
validation *and*
documentation. incidentally, it pretty much reflects the
current state,
except that it is hierarchic :-D

my suggestion is extensible, but it requires an element
hierarchy for
that - as you said, that's not desirable for internal
representation.

so how about this:

we define a grammar that can contain some fixed
lenya-internal metadata
items from a special namespace "lenya-meta:".
these are validatated in a
very thorough way, and must be represented 1:1 in the
grammar, leading
to a well-defined api and good documentation.
at the same time, the grammar can contain arbitrary elements
from other
namespaces, where people can dump their custom stuff.



-- 
"Án nýrra verka, án nútimans, hættir fortíðin
að vekja áhuga."
"Without new works, without the present the past will
cease to be of
interest."
        - Ásmundur Sveinsson (1893-1982)

--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-adminuni-due.de, Telefon: 0203/379-2736


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Joern Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Hi Jörn,
>>
>> IMO the problem about this schema is that it is not
generic,
>> i.e. it is not possible to add custom meta data
sets without
>> changing the schema. 
> 
> that's a feature.

Well, IMO Lenya should behave like a framework and define
the
structure of the meta data, but not the actual content. It
should
be possible to add components without modifying the core.
What
if you want to use a custom Workflow component which
doesn't use
version elements to store meta data, or something like that?

[...]


> SoC at its very best, and totally useless for both
validation *and*
> documentation.

In the case of meta data, validation and documentation
shouldn't
be applied to the XML format. The format is just a
representation
of the internal meta data. The actual validation is done
when
the meta data are entered via the API
(MetaDataManager.setValue()
or something like that).

The internal meta data are not meant to be transmitted
between
applications, for this purpose you would provide explicit
interfaces.
These interfaces could make use of a special grammar.

Actually, I would like to introduce something like
"private"
meta data, which can only be accessed by a certain
component.
This would apply for instance to workflow meta data. They
wouldn't
be exposed by the LenyaMetaDataGenerator etc.


> incidentally, it pretty much reflects the current
state,
> except that it is hierarchic :-D
> 
> my suggestion is extensible, but it requires an element
hierarchy for
> that - as you said, that's not desirable for internal
representation.
> 
> so how about this:
> 
> we define a grammar that can contain some fixed
lenya-internal metadata
> items from a special namespace
"lenya-meta:". these are validatated in a
> very thorough way, and must be represented 1:1 in the
grammar, leading
> to a well-defined api and good documentation.

IMO the well-defined API and documentation should be handled
by
declaring meta data sets. The declaration would serve as a
configuration
for the meta data management component, which would be
reponsible to
validate values.

-- Andreas


-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
andreas.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org