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? or should we better not touch what works?
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.
* 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? 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.
* 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.
regards,
jörn
--
"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]
