Jörn Nettingsmeier wrote:
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Lenya Wiki"
for change notification.
The following page has been changed by JörnNettingsmeier:
http://wiki.apache.org/lenya/LenyaSpecificXMLNamespaces
------------------------------------------------------------------------------
== lenya:* http://apache.org/cocoon/lenya/page-envelope/1.0 ==
oh my god. hope i'm not stepping on anyone's toes here, but the element
definitions for that namespace in PageEnvelope.java (and all over the
place) are the most frightful pile of ad-hoc crap i've ever seen. no
regard for orthogonality, no hierarchy, just a dumpster for years of
"neat feature of the day" ideas...
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
imnsho there needs to be a watertight textual definition of what's legal
in any namespace, not a loose "add whatever you need" policy distributed
across a number of sourcefiles in totally unrelated packages.
<dream target="lenya 2.0">i don't know if it's worth it or whether it
will be efficient, but wouldn't it be a lot nicer to have a clean,
authoritative grammar defined in either rng or xsd, and java beans to
mimic this grammar 1:1 internally, including hierarchical data?</dream>
for the time being, there are a few unclear issues:
* 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.
* 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.
What we need is modularized meta data, i.e. components can define
their own meta data sets.
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
* 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.
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.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
