You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2006/08/15 16:17:07 UTC
[1.4] Uniform document addressing syntax
Hi Lenya devs,
IMO it would be very convenient to agree on a uniform syntax for
addressing documents. This could be used as a parameter for the
doc-info module, for internal links, etc.
The parameters which have to be contained are
- publication ID
- area
- uuid
- language
My first idea would be to use the current syntax of the doc-info module:
{pubId}:{area}:{uuid}:{language}
e.g.
default:authoring:23e40a90-2c68-11db-a98b-0800200c9a66:en
The doc-info module could be invoked for the currently requested
document using one of these expressions (choose which you like most):
{doc-info:{page-envelope:document-address}:path}
{doc-info:{page-envelope:document-identifier}:path}
...
An internal link URL might look like this:
document://{pubId}:{area}:{uuid}:{language}
Which protocol name should we use?
Thanks for any comments!
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Joern Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Hi Joern,
>>>
>>> thanks for your comprehensive comments!
>>
>>>> * are UUIDs unique across publications?
>>>> -> if yes, {pubId} is redundant. do we want to drag it along?
>>> It would be great if we could omit it, but this would require a
>>> performant lookup mechanism. Or we just put all content in a
>>> single box, and add the publication ID to the meta data. This
>>> sounds quite appealing to me.
>>
>> +1 for all-in-one-box, but -1 for adding it to the per-{UUID+lang}
>> metadata. that's suboptimal from an index efficiency pov. the
>> publication should maintain a list of which UUIDs belong to it. this is
>> also easier to debug, since you can see everything at one glance.
>
> Is this list really necessary? Maybe we can just assume that a publication
> "contains" all documents which are referenced in its site structure.
> According to your area interpretation, that would mean a global trash,
> though. But with a lucene index for the publication-id meta data attribute,
> searching the trash wouldn't be a big issue.
i don't like a global trash at all.
and i don't buy the "lucene index as a core mapping mechanism", until it
has been demonstrated that
a) we have a watertight re-indexing trigger with no concurrency issues;
b) our indexing handles access control restrictions correctly in all
cases, and does not leak protected information via the search results page.
>> moreover, the property "belonging to <pub>" is orthogonal to revisions,
>
> Is it? Moving a document to a different publication would mean that the
> next revision has a different "belongs to <pub>" value than the former one.
we should not bother about moving documents. if users want to do it,
they can copy the content, paste it into some other pub and delete it in
the old one. moving stuff around including history, revisions and
metadata is a world of pain once you start thinking about access
control, and frankly i think it's not worth it.
>>>> [terminology]
>>>>
>> 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.
>
> IMO that is a page, which is created by expanding a document.
> Expanding means that all inclusions are resolved, e.g. the document might
> be a list of <ci:include> statements, but the page shows a list of blog
> messages.
yeah, obviously correct, solprovider mentioned the same. since it is
just an example, let's get rid of it.
>> documents are uniquely identified by *UUIDs*, which may therefore be
>> called *document UUIDs* for extra clarity.
>
> +1
>
>> documents contain one or more *translations*. "translation" here refers
>> to the actual content, and includes the "original language version",
>> being a general category.
>> each translation has *metadata* associated with it.
>
> +1, whereas the document has meta data as well which apply to all
> translations.
not yet iiuc. or does it? but i would welcome such a scheme.
>>> lenya:// is one layer below this, it addresses repository nodes.
>>
>> does that mean that it's obsolete now? or if not, what is it currently
>> used for?
>
> It's used for addressing repository nodes. For instance, each document
> has a repository node for the content and one for the meta data, and the
> sitetree has a repository node for its XML, and so on. You shouldn't use
> lenya:// in a pipeline, it is for internal use only.
C|N>K
ah. i see.
hear, ye users: you are using a cms named lenya. it implements a source
factory with a protocol "lenya". it adresses repository nodes (as you
may have readily inferred from the name), but you are not to use it,
it's for internal use only.
this is a most brilliant specimen of a naming (and namespace) fuck-up,
and illustrates my point quite well :-D
--
"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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Hi Joern,
>>
>> thanks for your comprehensive comments!
>
>>> * are UUIDs unique across publications?
>>> -> if yes, {pubId} is redundant. do we want to drag it along?
>> It would be great if we could omit it, but this would require a
>> performant lookup mechanism. Or we just put all content in a
>> single box, and add the publication ID to the meta data. This
>> sounds quite appealing to me.
>
> +1 for all-in-one-box, but -1 for adding it to the per-{UUID+lang}
> metadata. that's suboptimal from an index efficiency pov. the
> publication should maintain a list of which UUIDs belong to it. this is
> also easier to debug, since you can see everything at one glance.
Is this list really necessary? Maybe we can just assume that a publication
"contains" all documents which are referenced in its site structure.
According to your area interpretation, that would mean a global trash,
though. But with a lucene index for the publication-id meta data attribute,
searching the trash wouldn't be a big issue.
> moreover, the property "belonging to <pub>" is orthogonal to revisions,
Is it? Moving a document to a different publication would mean that the
next revision has a different "belongs to <pub>" value than the former one.
> while per-{UUID+lang} metadata is not.
>
>>> * UUIDs are definitely orthogonal to revisions. we do not need to access
>>> revisions other than "current" most of the time, but we should make it
>>> possible now in order to avoid having to tack on another mechanism for
>>> situations where revisions are involved.
>> +1, this sounds useful.
>
> so the "unique index" to borrow from database theory would be tuple
> {UUID+lang+revision}
Yes, that would be the primary key.
>>> [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.
>> At the moment, a document is a particular translation in a particular
>> area in a particular publication (we didn't yet change the terminology,
>> at least as far as the class names are concerned).
>>
>> IIRC we agreed upon the term "translation" for this.
>> We don't have a class for "the object that contains all translations
>> for a UUID in a certain area" yet. That would be a document/resource/asset
>> (IIRC "document" was the preferred term).
>
> 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.
IMO that is a page, which is created by expanding a document.
Expanding means that all inclusions are resolved, e.g. the document might
be a list of <ci:include> statements, but the page shows a list of blog
messages.
> documents are uniquely identified by *UUIDs*, which may therefore be
> called *document UUIDs* for extra clarity.
+1
> documents contain one or more *translations*. "translation" here refers
> to the actual content, and includes the "original language version",
> being a general category.
> each translation has *metadata* associated with it.
+1, whereas the document has meta data as well which apply to all
translations.
> the terms MUST, MUST NOT and SHOOTING OFFENSE are to interpreted as
> described in RFC2119.
> </sections>
>
>>> [areas]
>>>
>>> thinking about andreas' suggestion, it becomes ever more evident to me
>>> that the area concept is flawed. areas should be done in altogether in
>>> the not too far future.
>> I agree that it has to be reconsidered, but should we address in 1.4?
>
> HELL NO! :-D
>
> this is 1.5 stuff. but i should think that the 1.4 cycle will be short
> anyway.
>
>>>> An internal link URL might look like this:
>>>>
>>>> document://{pubId}:{area}:{uuid}:{language}
>>> what about lenya: and lenyadoc:? i must confess i have never quite
>>> grasped the concept...
>> lenya:// is one layer below this, it addresses repository nodes.
>
> does that mean that it's obsolete now? or if not, what is it currently
> used for?
It's used for addressing repository nodes. For instance, each document
has a repository node for the content and one for the meta data, and the
sitetree has a repository node for its XML, and so on. You shouldn't use
lenya:// in a pipeline, it is for internal use only.
>> lenyadoc:// is probably fine for links. Maybe we should just use that one.
>
>>> in any case, the protocol should definitely begin with "lenya...", so
>>> that it's immediately obvious what's going on in the sitemap.
>>>
>>> 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 would greatly reduce the learning curve for our users, and make
>>> life easier for casual committers from other apache projects, since it's
>>> obvious if custom magic is at work, as opposed to core cocoon
>>> functionality.
>> -0.5, I'd prefer to keep them short, but it's OK with me to change it.
>
> i strongly feel that cocoon namespaces must be restructured, even at the
> cost of increased verbosity. it should be easy to register both the
> traditional and the prefixed name for a grace period, and move the
> sitemaps over piecemeal without breaking external code too soon.
OK, what do the others think?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by so...@apache.org.
[Snip from Andreas' response]
On 8/16/06, Andreas Hartmann <an...@apache.org> 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 <po...@uni-duisburg.de> wrote:
> solprovider@apache.org 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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Bhavya Sharma wrote:
> Hi i just want to know that how can i implement search in lenya,
> so that i can search my customized document also,
bhavya, unless you are prepared to learn and adhere to the basic forms
of conduct on mailing liste, you will make it into everybody's killfile
before getting any help.
--
"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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@lenya.apache.org
For additional commands, e-mail: user-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Bhavya Sharma wrote:
> Hi i just want to know that how can i implement search in lenya,
> so that i can search my customized document also,
bhavya, unless you are prepared to learn and adhere to the basic forms
of conduct on mailing liste, you will make it into everybody's killfile
before getting any help.
--
"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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by Bhavya Sharma <bh...@gmail.com>.
Hi i just want to know that how can i implement search in lenya,
so that i can search my customized document also,
Bhavya
Re: UUID musings and area bashing
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
solprovider@apache.org 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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by so...@apache.org.
There was no possibility I could ignore that subject line.
On 8/15/06, Joern Nettingsmeier <po...@uni-due.de> wrote:
> Andreas Hartmann wrote:
> >> * are UUIDs unique across publications?
> >> -> if yes, {pubId} is redundant. do we want to drag it along?
> > It would be great if we could omit it, but this would require a
> > performant lookup mechanism. Or we just put all content in a
> > single box, and add the publication ID to the meta data. This
> > sounds quite appealing to me.
> +1 for all-in-one-box, but -1 for adding it to the per-{UUID+lang}
> metadata. that's suboptimal from an index efficiency pov. the
> publication should maintain a list of which UUIDs belong to it. this is
> also easier to debug, since you can see everything at one glance.
> moreover, the property "belonging to <pub>" is orthogonal to revisions,
> while per-{UUID+lang} metadata is not.
Speaking from the future, it is possible to put all Resources into one
datastore. We would need to make the SitetreeGenerator aware that it
must select based on Publication when using a flat Index, but that
would be easy.
> >> * UUIDs are definitely orthogonal to revisions. we do not need to access
> >> revisions other than "current" most of the time, but we should make it
> >> possible now in order to avoid having to tack on another mechanism for
> >> situations where revisions are involved.
> > +1, this sounds useful.
> so the "unique index" to borrow from database theory would be tuple
> {UUID+lang+revision}
"live" is the name of the "current" Revision. "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.)
1.3's content: protocol uses "UUID_language!revision". But the
current language and "live" revision are assumed if they are omitted,
so the following return the same resource (assuming "en" is the
current language):
content:/uuid
content:/uuid_en!live
> >> [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.
> > At the moment, a document is a particular translation in a particular
> > area in a particular publication (we didn't yet change the terminology,
> > at least as far as the class names are concerned).
> > IIRC we agreed upon the term "translation" for this.
> > We don't have a class for "the object that contains all translations
> > for a UUID in a certain area" yet. That would be a document/resource/asset
> > (IIRC "document" was the preferred term).
I still feel that "document" is too closely associated with "XML
Document" to be used for all resources in a product based on XML.
While there are also "MSWord Documents" and "PDF Documents", they are
not "Documents" in Lenya. It also feels weird to refer to "JPEG
Documents" and "GIF Documents". 1.2 referred to JPEGs and GIFs (and
MSWord Documents and PDFs) as "Assets", but the distinction between
Documents and Assets is not relevant to the code in 1.3, so 1.3 calls
them all "Resources". Resources have types "xml", "file", "link", and
(coming soon) "text". An XML Document is an "xml" Resource. An
MSWord Document is a "file" Resource. There is no need to constantly
define the terms so people understand this usage.
We can start this discussion again when others start working on 1.3.
> 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.)
> documents are uniquely identified by *UUIDs*, which may therefore be
> called *document UUIDs* for extra clarity.
Documents/Resources. UUIDs/UNIDs.
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 UUID is a UNID. I have not written the UNID generator yet (because
1.3 does not have the ability to add Resources yet), but I plan to use
UUIDs as UNIDs. There is no reason not to use UUIDs as the UNIDs, but
the code is more flexible with UNIDs. (And I don't have to touch the
complicated 1.2->1.3 migration routine again. It will be easier to
force all non-UUID UNIDs to UUIDs later if we decide to remove the
flexibility. I expect the files->JCR migration to do something like
that.)
> documents contain one or more *translations*. "translation" here refers
> to the actual content, and includes the "original language version",
> being a general category.
> each translation has *metadata* associated with it.
>
> the terms MUST, MUST NOT and SHOOTING OFFENSE are to interpreted as
> described in RFC2119.
> </sections>
>
> >> [areas]
> >> thinking about andreas' suggestion, it becomes ever more evident to me
> >> that the area concept is flawed. areas should be done in altogether in
> >> the not too far future.
> > I agree that it has to be reconsidered, but should we address in 1.4?
> HELL NO! :-D
> this is 1.5 stuff. but i should think that the 1.4 cycle will be short
> anyway.
Heavy agreement. Just complete 1.4. Then come to 1.3 where Areas are
almost forgotten. (Some of the backwards-compatibility code still
uses the term, but the functions are deprecated.)
> >>> An internal link URL might look like this:
> >>> document://{pubId}:{area}:{uuid}:{language}
> >> what about lenya: and lenyadoc:? i must confess i have never quite
> >> grasped the concept...
> > lenya:// is one layer below this, it addresses repository nodes.
> does that mean that it's obsolete now? or if not, what is it currently
> used for?
> > lenyadoc:// is probably fine for links. Maybe we should just use that one.
> >> in any case, the protocol should definitely begin with "lenya...", so
> >> that it's immediately obvious what's going on in the sitemap.
> >> 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 would greatly reduce the learning curve for our users, and make
> >> life easier for casual committers from other apache projects, since it's
> >> obvious if custom magic is at work, as opposed to core cocoon
> >> functionality.
> > -0.5, I'd prefer to keep them short, but it's OK with me to change it.
> i strongly feel that cocoon namespaces must be restructured, even at the
> cost of increased verbosity. it should be easy to register both the
> traditional and the prefixed name for a grace period, and move the
> sitemaps over piecemeal without breaking external code too soon.
This is all specific to 1.4 The fallback:protocol is rather mindless,
and is another well-forgotten concept in 1.3. 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.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Andreas Hartmann wrote:
> Hi Joern,
>
> thanks for your comprehensive comments!
>> * are UUIDs unique across publications?
>> -> if yes, {pubId} is redundant. do we want to drag it along?
>
> It would be great if we could omit it, but this would require a
> performant lookup mechanism. Or we just put all content in a
> single box, and add the publication ID to the meta data. This
> sounds quite appealing to me.
+1 for all-in-one-box, but -1 for adding it to the per-{UUID+lang}
metadata. that's suboptimal from an index efficiency pov. the
publication should maintain a list of which UUIDs belong to it. this is
also easier to debug, since you can see everything at one glance.
moreover, the property "belonging to <pub>" is orthogonal to revisions,
while per-{UUID+lang} metadata is not.
>> * UUIDs are definitely orthogonal to revisions. we do not need to access
>> revisions other than "current" most of the time, but we should make it
>> possible now in order to avoid having to tack on another mechanism for
>> situations where revisions are involved.
>
> +1, this sounds useful.
so the "unique index" to borrow from database theory would be tuple
{UUID+lang+revision}
>> [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.
>
> At the moment, a document is a particular translation in a particular
> area in a particular publication (we didn't yet change the terminology,
> at least as far as the class names are concerned).
>
> IIRC we agreed upon the term "translation" for this.
> We don't have a class for "the object that contains all translations
> for a UUID in a certain area" yet. That would be a document/resource/asset
> (IIRC "document" was the preferred term).
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.
documents are uniquely identified by *UUIDs*, which may therefore be
called *document UUIDs* for extra clarity.
documents contain one or more *translations*. "translation" here refers
to the actual content, and includes the "original language version",
being a general category.
each translation has *metadata* associated with it.
the terms MUST, MUST NOT and SHOOTING OFFENSE are to interpreted as
described in RFC2119.
</sections>
>> [areas]
>>
>> thinking about andreas' suggestion, it becomes ever more evident to me
>> that the area concept is flawed. areas should be done in altogether in
>> the not too far future.
>
> I agree that it has to be reconsidered, but should we address in 1.4?
HELL NO! :-D
this is 1.5 stuff. but i should think that the 1.4 cycle will be short
anyway.
>>> An internal link URL might look like this:
>>>
>>> document://{pubId}:{area}:{uuid}:{language}
>>
>> what about lenya: and lenyadoc:? i must confess i have never quite
>> grasped the concept...
>
> lenya:// is one layer below this, it addresses repository nodes.
does that mean that it's obsolete now? or if not, what is it currently
used for?
> lenyadoc:// is probably fine for links. Maybe we should just use that one.
>> in any case, the protocol should definitely begin with "lenya...", so
>> that it's immediately obvious what's going on in the sitemap.
>>
>> 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 would greatly reduce the learning curve for our users, and make
>> life easier for casual committers from other apache projects, since it's
>> obvious if custom magic is at work, as opposed to core cocoon
>> functionality.
>
> -0.5, I'd prefer to keep them short, but it's OK with me to change it.
i strongly feel that cocoon namespaces must be restructured, even at the
cost of increased verbosity. it should be easy to register both the
traditional and the prefixed name for a grace period, and move the
sitemaps over piecemeal without breaking external code too soon.
--
"I don't need backups. I need restore!" - Trad.
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: UUID musings and area bashing
Posted by Andreas Hartmann <an...@apache.org>.
Hi Joern,
thanks for your comprehensive comments!
[...]
> iiuc, the only change to the old document-id semantics is that UUIDs are
> sitetree-agnostic, i.e. IDs remain constant when documents are moved
> around. correct?
Yes, exactly.
> hence,
>
> * UUIDs contain different translations
> -> we need UUID+{language}
>
> * UUIDs are shared among areas and revisions, i.e. the same UUID refers
> to a number of physical storage directories.
> -> we need UUID+{language}+{area} and assume current revision
>
> * are UUIDs unique across publications?
> -> if yes, {pubId} is redundant. do we want to drag it along?
It would be great if we could omit it, but this would require a
performant lookup mechanism. Or we just put all content in a
single box, and add the publication ID to the meta data. This
sounds quite appealing to me.
> do we have to rethink the design to restore orthogonality?
> -> if no, what's "unique" about them?
>
> * UUIDs are definitely orthogonal to revisions. we do not need to access
> revisions other than "current" most of the time, but we should make it
> possible now in order to avoid having to tack on another mechanism for
> situations where revisions are involved.
+1, this sounds useful.
> [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.
At the moment, a document is a particular translation in a particular
area in a particular publication (we didn't yet change the terminology,
at least as far as the class names are concerned).
IIRC we agreed upon the term "translation" for this.
We don't have a class for "the object that contains all translations
for a UUID in a certain area" yet. That would be a document/resource/asset
(IIRC "document" was the preferred term).
> this needs a new word that we must all instantly begin to use, and after
> a grace period of 10 days, anyone caught confusing terminology should be
> shot.
>
> [areas]
>
> thinking about andreas' suggestion, it becomes ever more evident to me
> that the area concept is flawed. areas should be done in altogether in
> the not too far future.
I agree that it has to be reconsidered, but should we address in 1.4?
> here's why:
>
> * areas currently imply multiple storage units with the same UUID. not nice.
>
> * admin, trash and site areas are second-class citizens and are not
> conceptually similar enough to warrant being called "areas".
>
> * trash can go, since any UUID not currently referenced from the site
> tree would be "in trash". that implies not throwing an exception
> like we do now. trash would become a usecase that allows for
> comfortable browsing of such "orphaned" UUID entities.
>
> * most importantly, areas are *not orthogonal* to revisions. "live" can
> become just another site-tree. this time pointing not just to UUIDs, but
> to UUID+revision. authoring otoh implies "HEAD" revision on all UUIDs.
>
>
>> An internal link URL might look like this:
>>
>> document://{pubId}:{area}:{uuid}:{language}
>
> what about lenya: and lenyadoc:? i must confess i have never quite
> grasped the concept...
lenya:// is one layer below this, it addresses repository nodes.
lenyadoc:// is probably fine for links. Maybe we should just use that one.
> in any case, the protocol should definitely begin with "lenya...", so
> that it's immediately obvious what's going on in the sitemap.
>
> 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 would greatly reduce the learning curve for our users, and make
> life easier for casual committers from other apache projects, since it's
> obvious if custom magic is at work, as opposed to core cocoon functionality.
-0.5, I'd prefer to keep them short, but it's OK with me to change it.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
UUID musings and area bashing
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> IMO it would be very convenient to agree on a uniform syntax for
> addressing documents. This could be used as a parameter for the
> doc-info module, for internal links, etc.
++votes**2
> The parameters which have to be contained are
>
> - publication ID
> - area
> - uuid
> - language
thinking out loud, correct me if i'm wrong.
iiuc, the only change to the old document-id semantics is that UUIDs are
sitetree-agnostic, i.e. IDs remain constant when documents are moved
around. correct?
hence,
* UUIDs contain different translations
-> we need UUID+{language}
* UUIDs are shared among areas and revisions, i.e. the same UUID refers
to a number of physical storage directories.
-> we need UUID+{language}+{area} and assume current revision
* are UUIDs unique across publications?
-> if yes, {pubId} is redundant. do we want to drag it along?
do we have to rethink the design to restore orthogonality?
-> if no, what's "unique" about them?
* UUIDs are definitely orthogonal to revisions. we do not need to access
revisions other than "current" most of the time, but we should make it
possible now in order to avoid having to tack on another mechanism for
situations where revisions are involved.
[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 needs a new word that we must all instantly begin to use, and after
a grace period of 10 days, anyone caught confusing terminology should be
shot.
[areas]
thinking about andreas' suggestion, it becomes ever more evident to me
that the area concept is flawed. areas should be done in altogether in
the not too far future.
here's why:
* areas currently imply multiple storage units with the same UUID. not nice.
* admin, trash and site areas are second-class citizens and are not
conceptually similar enough to warrant being called "areas".
* trash can go, since any UUID not currently referenced from the site
tree would be "in trash". that implies not throwing an exception
like we do now. trash would become a usecase that allows for
comfortable browsing of such "orphaned" UUID entities.
* most importantly, areas are *not orthogonal* to revisions. "live" can
become just another site-tree. this time pointing not just to UUIDs, but
to UUID+revision. authoring otoh implies "HEAD" revision on all UUIDs.
> An internal link URL might look like this:
>
> document://{pubId}:{area}:{uuid}:{language}
what about lenya: and lenyadoc:? i must confess i have never quite
grasped the concept...
in any case, the protocol should definitely begin with "lenya...", so
that it's immediately obvious what's going on in the sitemap.
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 would greatly reduce the learning curve for our users, and make
life easier for casual committers from other apache projects, since it's
obvious if custom magic is at work, as opposed to core cocoon functionality.
(since most parts of this mail is only distantly related to andreas'
original inquiry, i suggest you consider replying directly to his mail
and only follow this thread if you want to comment specifically on my
ranting.)
jörn
--
"I don't need backups. I need restore!" - Trad.
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Joachim Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>> Hi Lenya devs,
>>
>> IMO it would be very convenient to agree on a uniform syntax for
>> addressing documents. This could be used as a parameter for the
>> doc-info module, for internal links, etc.
>>
>> The parameters which have to be contained are
>>
>> - publication ID
>> - area
>> - uuid
>> - language
>>
>> My first idea would be to use the current syntax of the doc-info module:
>>
>> {pubId}:{area}:{uuid}:{language}
>>
>> e.g.
>>
>> default:authoring:23e40a90-2c68-11db-a98b-0800200c9a66:en
>
> Hi Andreas,
> (maybe I'm missing something, but) it seems strange to have publication
> ID and area as part of the syntax of an internal link. These should only
> point to documents within the same publication and area, shouldn't they?
> If so, they should be implicit.
important point imho.
(btw, wolfgang, i only just realized we work at the same shop... would
like to meet for a cup of coffee the other day?)
jörn
--
"I don't need backups. I need restore!" - Trad.
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Joachim Wolfgang Kaltz <jo...@uni-duisburg-essen.de>.
Andreas Hartmann schrieb:
> Joachim Wolfgang Kaltz wrote:
>
> [...]
>
>> Hi Andreas,
>> (maybe I'm missing something, but) it seems strange to have
>> publication ID and area as part of the syntax of an internal link.
>> These should only point to documents within the same publication and
>> area,
>
>
> IMO it should be allowed to point to documents from other publications.
> Imagine you have a university/company website with a lot of publications,
> I wouldn't restrict the links to point to the same publication.
Sure, but the question is, are those Lenya-internal links?
Internal implies some kind of intelligence: knowing how to resolve the
link (within this current publication), knowing about the status of the
linked page, being able to help in the publishing process (e.g. "you are
publishing a page which contains a link to a non-published page")
I don't think that makes sense across publications, as each publication
may have very different mechanisms (for workflows, for resolving links, ...)
>
> Concerning the area, you are certainly right.
> Should we exclude the area from link URLs?
+1 AFAICS
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@apache.org wrote:
> On 8/15/06, Andreas Hartmann <an...@apache.org> wrote:
>> IMO the UUID should be orthogonal to the publication which the
>> document belongs to. The UUID is forever, even when you move the
>> document to a different publication.
>>
>> I think the most reasonable way is to use a common storage for all
>> documents, regardless of the publication they belong to.
>
> In Domino, within a Database each Document has a ReplicaID used to
> synchronize the Documents in all Replicas of the Database. If a new
> Replica (exact copy that can be synchronized) of the Database is
> created, the ReplicaIDs are not changed. If a new Copy of the
> Database is created, all the Documents are assigned a new ReplicaID.
> If the Document is copied to another Database, it is assigned a new
> ReplicaID. If the Document can be copied to the same Database, the
> copy is assigned a new ReplicaID.
>
> For Lenya terms, replace Database with Publication, and ReplicaID with
> UUID. Do we have a term for a Publication that stays synchronized
> with another Publication?
No, AFAIK this hasn't been implemented yet.
> If a Document retains its UUID when it is copied to a different
> Publication, then the two Documents should contain the same
> information. This requires frequent communication between the
> Publications. Does Lenya have that ability?
IMO copying a document to a different publication should create a
new document with a new UUID. But moving the document should leave
the UUID as it was.
> If copies of a Document will not remain synchronized, the UUID should
> be changed during the copy operation.
>
> ---
> In my last post, I suggested that containing Documents for multiple
> Publications in one datastore would be easy. That implies multiple
> Publications can contain the same Document. But they would share the
> same physical instance of the Document; if it is changed, all the
> Publications would show the change.
Yes, IMO that makes sense.
> If the Document is Copied within a Publication, it must be assigned a
> new UUID, or there will be conflicts.
+1
> If multiple Publications are
> sharing the datastore, and the Document is Copied from one Publication
> to another, the Document must be assigned a new UUID. The two copies
> share everything up to the point of Copying, but then they are
> maintained separately, and must have their own unique identifiers.
Sounds reasonable.
-- Andreas
> ---
> Joern,
> Each UUID is supposed to be unique in the world. There are enough of
> them that we cannot exhaust them. Of course, their uniqueness depends
> on the generators. If two generators start with the same number and
> increment sequentially, they will produce duplicates. All modern
> generators are supposed to generate UUIDs that are part random, part
> time-based, and part based on the source of the UUID. There are a
> finite number of them, and statistically there must be a collision
> someday, but it is expected the universe will end before a meaningful
> collision occurs.
>
> solprovider
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by so...@apache.org.
On 8/15/06, Andreas Hartmann <an...@apache.org> wrote:
> IMO the UUID should be orthogonal to the publication which the
> document belongs to. The UUID is forever, even when you move the
> document to a different publication.
>
> I think the most reasonable way is to use a common storage for all
> documents, regardless of the publication they belong to.
In Domino, within a Database each Document has a ReplicaID used to
synchronize the Documents in all Replicas of the Database. If a new
Replica (exact copy that can be synchronized) of the Database is
created, the ReplicaIDs are not changed. If a new Copy of the
Database is created, all the Documents are assigned a new ReplicaID.
If the Document is copied to another Database, it is assigned a new
ReplicaID. If the Document can be copied to the same Database, the
copy is assigned a new ReplicaID.
For Lenya terms, replace Database with Publication, and ReplicaID with
UUID. Do we have a term for a Publication that stays synchronized
with another Publication?
If a Document retains its UUID when it is copied to a different
Publication, then the two Documents should contain the same
information. This requires frequent communication between the
Publications. Does Lenya have that ability?
If copies of a Document will not remain synchronized, the UUID should
be changed during the copy operation.
---
In my last post, I suggested that containing Documents for multiple
Publications in one datastore would be easy. That implies multiple
Publications can contain the same Document. But they would share the
same physical instance of the Document; if it is changed, all the
Publications would show the change.
If the Document is Copied within a Publication, it must be assigned a
new UUID, or there will be conflicts. If multiple Publications are
sharing the datastore, and the Document is Copied from one Publication
to another, the Document must be assigned a new UUID. The two copies
share everything up to the point of Copying, but then they are
maintained separately, and must have their own unique identifiers.
---
Joern,
Each UUID is supposed to be unique in the world. There are enough of
them that we cannot exhaust them. Of course, their uniqueness depends
on the generators. If two generators start with the same number and
increment sequentially, they will produce duplicates. All modern
generators are supposed to generate UUIDs that are part random, part
time-based, and part based on the source of the UUID. There are a
finite number of them, and statistically there must be a collision
someday, but it is expected the universe will end before a meaningful
collision occurs.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Andreas Hartmann wrote:
> Joern Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Joachim Wolfgang Kaltz wrote:
>>>
>>> [...]
>>>
>>>> Hi Andreas,
>>>> (maybe I'm missing something, but) it seems strange to have
>>>> publication ID and area as part of the syntax of an internal link.
>>>> These should only point to documents within the same publication and
>>>> area,
>>> IMO it should be allowed to point to documents from other publications.
>>> Imagine you have a university/company website with a lot of
>>> publications,
>>> I wouldn't restrict the links to point to the same publication.
>>
>> that's true. but i wonder: does the UUID algorithm not guarantee
>> uniqueness even across publications? if so, all we would need is a list
>> of "external publications" for reference that maps pub-ids to UUID
>> prefixes. it could go into publication.xconf.
>
> IMO the UUID should be orthogonal to the publication which the
> document belongs to. The UUID is forever, even when you move the
> document to a different publication.
ah, ok, thanks for clarifying. somehow i thought that the UUIDs were
hierachic, like <document>-<pub>-<somemagic>-<somemoremagic>. but of
course that would quite defy the point.
> I think the most reasonable way is to use a common storage for all
> documents, regardless of the publication they belong to.
yes.
and before someone shouts "network transparency" and "linking to pubs on
other servers", that's probably quite simple if the original server acts
as proxy and requests any external pages itself before passing them to
the user....
--
"I don't need backups. I need restore!" - Trad.
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Andreas Hartmann <an...@apache.org>.
Joern Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Joachim Wolfgang Kaltz wrote:
>>
>> [...]
>>
>>> Hi Andreas,
>>> (maybe I'm missing something, but) it seems strange to have
>>> publication ID and area as part of the syntax of an internal link.
>>> These should only point to documents within the same publication and
>>> area,
>> IMO it should be allowed to point to documents from other publications.
>> Imagine you have a university/company website with a lot of publications,
>> I wouldn't restrict the links to point to the same publication.
>
> that's true. but i wonder: does the UUID algorithm not guarantee
> uniqueness even across publications? if so, all we would need is a list
> of "external publications" for reference that maps pub-ids to UUID
> prefixes. it could go into publication.xconf.
IMO the UUID should be orthogonal to the publication which the
document belongs to. The UUID is forever, even when you move the
document to a different publication.
I think the most reasonable way is to use a common storage for all
documents, regardless of the publication they belong to.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Joern Nettingsmeier <po...@uni-due.de>.
Andreas Hartmann wrote:
> Joachim Wolfgang Kaltz wrote:
>
> [...]
>
>> Hi Andreas,
>> (maybe I'm missing something, but) it seems strange to have
>> publication ID and area as part of the syntax of an internal link.
>> These should only point to documents within the same publication and
>> area,
>
> IMO it should be allowed to point to documents from other publications.
> Imagine you have a university/company website with a lot of publications,
> I wouldn't restrict the links to point to the same publication.
that's true. but i wonder: does the UUID algorithm not guarantee
uniqueness even across publications? if so, all we would need is a list
of "external publications" for reference that maps pub-ids to UUID
prefixes. it could go into publication.xconf.
that way, every link only contains an UUID, regardless of the
publication it's in.
--
"I don't need backups. I need restore!" - Trad.
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Andreas Hartmann <an...@apache.org>.
Joachim Wolfgang Kaltz wrote:
[...]
> Hi Andreas,
> (maybe I'm missing something, but) it seems strange to have publication
> ID and area as part of the syntax of an internal link. These should only
> point to documents within the same publication and area,
IMO it should be allowed to point to documents from other publications.
Imagine you have a university/company website with a lot of publications,
I wouldn't restrict the links to point to the same publication.
Concerning the area, you are certainly right.
Should we exclude the area from link URLs?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Joachim Wolfgang Kaltz <jo...@uni-duisburg-essen.de>.
Andreas Hartmann schrieb:
> Hi Lenya devs,
>
> IMO it would be very convenient to agree on a uniform syntax for
> addressing documents. This could be used as a parameter for the
> doc-info module, for internal links, etc.
>
> The parameters which have to be contained are
>
> - publication ID
> - area
> - uuid
> - language
>
> My first idea would be to use the current syntax of the doc-info module:
>
> {pubId}:{area}:{uuid}:{language}
>
> e.g.
>
> default:authoring:23e40a90-2c68-11db-a98b-0800200c9a66:en
Hi Andreas,
(maybe I'm missing something, but) it seems strange to have publication
ID and area as part of the syntax of an internal link. These should only
point to documents within the same publication and area, shouldn't they?
If so, they should be implicit.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Doug Chestnut <dh...@virginia.edu>.
Andreas Hartmann wrote:
> Doug Chestnut wrote:
>
>>
>>
>> Andreas Hartmann wrote:
>>
>>> Doug Chestnut wrote:
>>>
>>>>
>>>>
>>>> Andreas Hartmann wrote:
>>>>
>>>>> [...]
>>>>>
>>>>> An internal link URL might look like this:
>>>>>
>>>>> document://{pubId}:{area}:{uuid}:{language}
>>>>
>>>>
>>>> Do we really need to have the pubID contained in the internal
>>>> links? It would be really nice if we could resolve the pubId from
>>>> the uuid. I could see moving content from one pub to another with
>>>> ease.
>>>
>>>
>>>
>>> Yes, I also thought about this. But it raises the question of resolving
>>> the publication for a UUID. I see two approaches:
>>>
>>> - manage a global index
>>
>> Lucene? We already maintain an index of all documents. If we make
>> lucene a core module, we could perform a query for a doc with our uuid
>> (uuid field), then get the pub(s) the doc belongs to from the pubid
>> field.
>
>
> The problem I see here is that the index has to be available within a
> transaction. This means that a separate index has to be created for
> each session, or rather an "index change set" for performance reason.
> If this can be implemented in an easy way with Lucene, this might be
> an option
Yeah, from a quick google it doesn't look like lucene supports
transactions.
Compass looked interesting though:
http://www.opensymphony.com/compass/
--Doug
>
> -- Andreas
>
>> The sitetree file could be replaced by a parentDoc and childrenDoc
>> fields in the lucene index. The sitetree would be generated (and
>> cached?) from the lucene index.
>>
>> Want to have internal links between multiple lenya instances? Use the
>> solr module instead of the lucene module.
>>
>> In 1.5+ this function could be handled by a jcr search module or rdf
>> module?
>>
>> --Doug
>>
>>> - ask each publication if it contains the UUID
>>>
>>> Both options didn't seem very appealing to me, so I discarded
>>> this approach. But of course, moving content to a different
>>> publication can't be neglected, so we should really consider
>>> excluding the publication ID.
>>>
>>> -- Andreas
>>>
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Andreas Hartmann <an...@apache.org>.
Doug Chestnut wrote:
>
>
> Andreas Hartmann wrote:
>> Doug Chestnut wrote:
>>
>>>
>>>
>>> Andreas Hartmann wrote:
>>>
>>>> [...]
>>>>
>>>> An internal link URL might look like this:
>>>>
>>>> document://{pubId}:{area}:{uuid}:{language}
>>>
>>> Do we really need to have the pubID contained in the internal links?
>>> It would be really nice if we could resolve the pubId from the uuid.
>>> I could see moving content from one pub to another with ease.
>>
>>
>> Yes, I also thought about this. But it raises the question of resolving
>> the publication for a UUID. I see two approaches:
>>
>> - manage a global index
> Lucene? We already maintain an index of all documents. If we make
> lucene a core module, we could perform a query for a doc with our uuid
> (uuid field), then get the pub(s) the doc belongs to from the pubid field.
The problem I see here is that the index has to be available within a
transaction. This means that a separate index has to be created for
each session, or rather an "index change set" for performance reason.
If this can be implemented in an easy way with Lucene, this might be
an option.
-- Andreas
> The sitetree file could be replaced by a parentDoc and childrenDoc
> fields in the lucene index. The sitetree would be generated (and
> cached?) from the lucene index.
>
> Want to have internal links between multiple lenya instances? Use the
> solr module instead of the lucene module.
>
> In 1.5+ this function could be handled by a jcr search module or rdf
> module?
>
> --Doug
>
>> - ask each publication if it contains the UUID
>>
>> Both options didn't seem very appealing to me, so I discarded
>> this approach. But of course, moving content to a different
>> publication can't be neglected, so we should really consider
>> excluding the publication ID.
>>
>> -- Andreas
>>
>>
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Doug Chestnut <dh...@virginia.edu>.
Andreas Hartmann wrote:
> Doug Chestnut wrote:
>
>>
>>
>> Andreas Hartmann wrote:
>>
>>> [...]
>>>
>>> An internal link URL might look like this:
>>>
>>> document://{pubId}:{area}:{uuid}:{language}
>>
>> Do we really need to have the pubID contained in the internal links?
>> It would be really nice if we could resolve the pubId from the uuid.
>> I could see moving content from one pub to another with ease.
>
>
> Yes, I also thought about this. But it raises the question of resolving
> the publication for a UUID. I see two approaches:
>
> - manage a global index
Lucene? We already maintain an index of all documents. If we make
lucene a core module, we could perform a query for a doc with our uuid
(uuid field), then get the pub(s) the doc belongs to from the pubid field.
The sitetree file could be replaced by a parentDoc and childrenDoc
fields in the lucene index. The sitetree would be generated (and
cached?) from the lucene index.
Want to have internal links between multiple lenya instances? Use the
solr module instead of the lucene module.
In 1.5+ this function could be handled by a jcr search module or rdf module?
--Doug
> - ask each publication if it contains the UUID
>
> Both options didn't seem very appealing to me, so I discarded
> this approach. But of course, moving content to a different
> publication can't be neglected, so we should really consider
> excluding the publication ID.
>
> -- Andreas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Andreas Hartmann <an...@apache.org>.
Doug Chestnut wrote:
>
>
> Andreas Hartmann wrote:
>> [...]
>>
>> An internal link URL might look like this:
>>
>> document://{pubId}:{area}:{uuid}:{language}
> Do we really need to have the pubID contained in the internal links? It
> would be really nice if we could resolve the pubId from the uuid. I
> could see moving content from one pub to another with ease.
Yes, I also thought about this. But it raises the question of resolving
the publication for a UUID. I see two approaches:
- manage a global index
- ask each publication if it contains the UUID
Both options didn't seem very appealing to me, so I discarded
this approach. But of course, moving content to a different
publication can't be neglected, so we should really consider
excluding the publication ID.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Uniform document addressing syntax
Posted by Doug Chestnut <dh...@virginia.edu>.
Andreas Hartmann wrote:
> [...]
>
> An internal link URL might look like this:
>
> document://{pubId}:{area}:{uuid}:{language}
Do we really need to have the pubID contained in the internal links? It
would be really nice if we could resolve the pubId from the uuid. I
could see moving content from one pub to another with ease.
I also question why we need to include area in the internal links.
Would someone ever link from a live doc to a doc in authoring? There
has been discussion of removing areas, this would be one more thing to
untie later.
--Doug
>
> Which protocol name should we use?
>
> Thanks for any comments!
>
> -- Andreas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org