Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>
> [...]
>
>>>> * the LenyaMetaDataGenerator introduces a somewhat nicer structure
>>>> by using wrappers, but these need to be defined somehow. is there
>>>> general interest to have hierarchical metadata, or do you prefer
>>>> flat for internal use?
>>>
>>> IMO a flat structure is sufficient.
>>
>> ok, the new schema is flat. i have even flattened the "var:is_live"
>> thing into just a <isLive/> element. it's probably easier and more
>> concise to extend the schema when new var:foo fields are needed than
>> to build extensibility into the schema. this way, the schema can be
>> used as documentation.
>
> Hmmm - the is_live workflow variable is not generic, it is just a
> variable which is used by the default publication's workflow. I'm
> not yet familiar with your code - does it still support arbitrary
> workflow variables?
currently it does, but i'd rather get rid of it, and mandate that all
fields are defined in a grammar that is used for validation.
>>> We should abandon the concept of "custom" meta data and introduce
>>> modularized meta data instead. IMO this is not too complex and should
>>> be implemented for 1.4, since it affects the content repository.
>>
>> as michi remarked, it is important to be able to differentiate between
>> core metadata that is handled by lenya and must be backwards
>> compatible, and custom stuff that is just passed through as-is.
>
> I totally agree, but this is a different issue. We have several concern
> areas which are not necessarily related:
>
> 1) Backwards compatibility
>
> Since meta data are stored with the content, they must either
> be stable, or there must be a migration tool.
that's what i was aiming at: if we introduce modular, arbitraty
metadata, it should still be clear which is "core", meaning: for these
fields the maintainers will take care of backwards compatibility or
provide a migration tool.
> 2) Protection
>
> Maybe some meta data should be read-only, or only accessible from
> certain components.
important point. i hadn't thought of that...
that implies we should have a central component that handles all
metadata operations - i'm not familiar with the code, perhaps that is
already the case?
> 3) Validation
>
> It should be possible to define additional meta data sets which are
> used by custom components. The meta data should be validated, i.e.
> the set of keys is fixed.
hmmm. i don't understand. either the set of keys is fixed, or it's
possible to define addtional data sets... can you explain?
> I don't understand why (3) would violate (1) ...
it doesn't.
--
"Á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]
