Andreas Hartmann wrote:
Jörn Nettingsmeier wrote:
>
is there any interest in cleaning this up and deprecating some of the
more glaringly redundant fields?
+1
or should we better not touch what works?
-1, the code must be kept alive
ok, i have started with a relax ng schema proposal for a new meta data
generator that takes your comments into account. see my other post for
the actual schema.
* which of the fields defined in PageEnvelope.java (and in the page
evelope input module) are actually needed (and still being used) for
core lenya mechanisms (as opposed to "i could use this for my current
project, let's hack it in")? the wiki page is already becoming
unwieldy with just that one namespace.
IMO the page envelope should be removed entirely and replaced by
single-purpose modules. This process has already been started but
has never been finished.
ok, i won't be able to contribute much to that, it's too much code...
i'd rather concentrate on fixing things i already know a little about.
* 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.
What we need is modularized meta data, i.e. components can define
their own meta data sets.
the current schema allows for a <lenya-meta:custom/> element that can
contain arbitrary xml data, provided that the elements within are *not*
in the lenya:meta namespace.
if it turns out that the needs of the java coders are vastly different
than those of pipeline jugglers, then the metadata generator should
map the internal data on a different namespace with well-defined
semantics and not hijack the page envelope ns.
+1
done.
* another hairy issue is that magic "lenya:custom" tag, which
basically states that everything you care to dump here magically
becomes part of the page envelope namespace. here be dragons! either
let's change it to something like <lenya:customtag
name="key">value</lenya:customtag>, or require that people put those
custom tags in another namespace, as is the case with the dc: tags.
done, see above.
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.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
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]
