[EMAIL PROTECTED] wrote:
There was no possibility I could ignore that subject line.
hop on!
> "live" is the name of the "current" Revision.
no, it's not. "live" is one particular revision that has been published.
to speak in lenya 1.4 workflow terms, when a document has been published
and its state is "live", the live version is indeed the current one. but
if a document is in "review", the live one is an earlier revision. you
can't even assume it's the last-but-one, as there may have been
rejections and re-edits.
that reminds me of another point i wanted to make: the "this revision is
live" flag should not be in the per-document metadata, but in a global
index. this way, it's impossible that more than one revision carry that
flag due to a programming error or tinkering with the site tree (yes,
andreas, people like to do that :), and it's also vastly more efficient.
(this implies that if a revision is to be deleted for good (something
that we can't do currently, but it will have to be implemented some
day), the usecase must look the revision up in the global index to
ensure it is not live.)
"live" is shorter, and
backwards-compatible with 1.2 when it was famous as the name of the
primary "Area" (an obsolete concept used to scatter information about
a Resource into many locations to increase the difficulty of
administration.)
solprovider, you're being nasty. but in a quite entertaining way :)
>> [terminology]
>> are we realling "addressing documents"?
>> currently, i find in the sitemaps the term "document-uuid".
>> that implies we use the term "document" to mean "the set of all stored
>> data snippets (including meta) that corresponds to a particular UUID".
>> so we are not addressing documents. we are addressing particular
>> instances of a document in a certain publication, area and language.
This was fun to design. The content: protocol has three methods:
- DATA is the default, It returns the Resource's content: XML for
type "xml" and binary files for "file".
- META returns XML. For type "xml", the result is the same as DATA,
but it returns the associated "meta" xml for type "file".
- INFO returns XML describing structural information about a Resource,
including all Translations and the Revisions of each Translation.
i don't see how this could be useful.
why do you differenciate between "INFO" and "META"? "INFO" seems to
include what we currently call metadata in 1.4. what is the point of "META"?
how can the result of a query for "META" depend on the MIME type of DATA?
so let me propose the following:
<section status="draft" normative="yes">
the entirety of all data pertaining to what is traditionally called a
"web page" is called a *document* within lenya.
1.2 and 1.3 refer to a "web page" as a Page. (Think "PageEnvelope".)
You violate the above definition in the next section, because a "web
page" may be composed of more than one "document". (Think blogs.)
agreed. it was an off-the-cuff example, and a bad one. strike it out.
documents are uniquely identified by *UUIDs*, which may therefore be
called *document UUIDs* for extra clarity.
Documents/Resources. UUIDs/UNIDs.
care to expand those acronyms for me? i'm not sure i know the difference.
Documents are type of Resource, but what type of Resource changes
depending on the type of Document. I won't argue if others prefer
working with GIF Documents; I'll just assume English is not their
native language.
a good point.
>> i would even go as far as suggesting that all our input modules and
>> pseudo-protocols that are not suited for upstream cocoon be re-named
>> lenya-fallback, {lenya-docinfo:...} etc.
This is all specific to 1.4 The fallback:protocol is rather mindless,
and is another well-forgotten concept in 1.3.
actually, i find it one of the most beautiful concepts in lenya 1.4.
there are rough edges, and it can't really shine unless all the old
cruft has been cleared out, but we're getting there.
I have not used the
other protocols mentioned. Are any of them useful for something not
handled by the 1.3's content: and module: protocols? We can rename
1.3's protocols for better branding, but I prefer simplicity.
i'm not talking about branding, but about ease-of-learning and clean
namespaces. if everybody goes out and invents ad-hoc pseudo-protocols
all over the place, things can get ugly when you try to combine multiple
cocoon-based components. moreover, the sitemap code is needlessly hard
to understand when you don't know which of the gizmos you see are custom
and which are cocoon-core.
imnsho, you can either
* feed stuff upstream and clutter the global namespace (bad), or
* use a prefix that makes clashes reasonably improbable (good).
the fact that there is currently no policy against namespace pollution
is no excuse.
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]
