[Snip from Andreas' response]
On 8/16/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
Joern Nettingsmeier wrote:
> each translation has *metadata* associated with it.
+1, whereas the document has meta data as well which apply to all
translations.
In a much earlier discussion, the consensus was that metadata should
be revisioned with the data. That was implemented in 1.3. I am using
1.2's definition of metadata; see below for the explanation.
[Back to the main event]
On 8/16/06, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> "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.)
Yes, "live" is not the current working copy. 1.3 refers to that as
the "edit" Revision.
In 1.3 (too many of my sentences start with that), each Translation
has alternate labels for certain Revisions. The current
implementation has two labels: "live" and "edit". Each Revision can
be referenced by either its UNID and the label:
<Resource UNID="xxx">
<Translation language="en" live="123" edit="234">
<Revision UNID="111"/>
<Revision UNID="123"/>
<Revision UNID="222"/>
<Revision UNID="234"/>
<Revision UNID="333"/>
</Translation>
These pairs are equivalent:
content:/xxx_en!123
content:/xxx_en!live
content:/xxx_en!234
content:/xxx_en!edit
"live" is the currently published Revision. Saving creates a new
Revisions and moved the "edit" label to it. As workflow is developed,
more labels can easily be added.
I think this implementation meets your specifications.
> "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 :)
The subject is "Area Bashing". Just helping out.
>> >> [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?
In 1.2, metadata referred to XML attached to a binary file (Asset) and
the DC elements in a Document. I tried to keep that definition for
1.3, which resulted in the above design. Because the structural
information is now split between resource.xml, translation.xml, and
revision.xml, a new method was required to retrieve XML describing the
Resource's structure. I chose "INFO" because it was 4 letters easily
understood to mean "structural information".
>> so let me propose the following:
>> <section status="draft" normative="yes">
>> 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.
UNID = "Unique Identifier". It is any identifier guaranteed not to
conflict within its scope.
UUID = "Universally Unique Identifier". It is a particular format
(16-byte number) of UNID that should never conflict in this universe
or the next.
The 1.2->1.3 migration assigns UNIDs as "1", "2", "3", etc.. They
will not conflict within the Publication, but will obviously conflict
with any other migrated Publication. Code that handles UNIDs can
easily handle UUIDs; the only difference is the assignment process.
> 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 did not discard fallback: without a replacement.
The fallback: protocol assumes one level of predefined inheritance.
1.3's module: protocol allows multiple levels of dynamic inheritance.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
