[EMAIL PROTECTED] wrote:
{<module-name>:<pub-id>:<area>:<doc-id>:<doc-lang>:<p1>:<p2>:<...>:<px>}
{<module-name>:<pub-id>:<area>:<doc-lang>:<doc-id>:<p1>:<p2>:<...>:<px>}
I prefer extendable parameters after defined parameters, so I prefer
the last, but this is a cosmetic decision.
If the syntax with colons ':' is used, "extendable" parameters aren't
any issue any more. Andreas proposed to have the language parameter
before the doc-id. I would argue, that it's better to have it other
way round (<pub-id>:<area>:<doc-id>:<doc-lang>) to use the same
parameter order used in many (Java) interfaces. As said before,
the parameter order of the lenyadoc: protocol was set because of
technical limitations when '/' was used as parameter separator.
The pub-id should be before the module name. A publication can
override a global module, and can have publication-specific modules.
I don't think overwriting modules in publications is the way to go
because this adds a lot of complexity. What I would propose is to make
configurable which module is used, sort of component software.
I hope "area" will soon be replaced by modules. Are there any modules
that care about both "live" and "authoring"? Admin modules do not
care about either. Editing modules care about "authoring".
Functional modules (Search, Sitemap, Summaries) care about "live". If
a module does care about both, it can default to "live" unless a
module-specific parameter specifies "authoring".
I don't understand why you want to replace areas with modules. Areas are
an administrative structure related either to administrative tasks (
(admin, site) or to the workflow whereas modules are software components
which offers functionality to the application/publication.
If you propose to clearly separate workflow areas from administrative
areas I would give my +1.
I suggest:
{<pub-id>:<module-name>:<doc-lang>:<doc-id>:<p1>:<p2>:<...>:<px>}
This raises the question if we should even use the URL snippet for
the document locator, or rather a globally unique ID (either generated
by the system, or assigned upon document creation). This would allow
to match the document locator using a single asterisk, which would
probably simplify pipelines.
Other platforms wrap global identifiers in braces {}. So a document could be:
/hr/benefits_en.html
or
{2005120120070766} (Global identifiers are usually time-based to
prevent duplicates.)
Using braces could be a problem if the braces in this proposal are
meant to be the specification.
IIRC braces '{', '}' have a special meaning in Cocoon sitemaps.
- Felix
solprovider
--
Felix Röthenbacher [EMAIL PROTECTED]
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
