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: [EMAIL PROTECTED], Telefon: 0203/379-2736


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to