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/23 09:50:48 UTC
[1.4] Link syntax
Hi Lenya devs,
(I'm starting a new thread to keep the discussion focused on 1.4)
The last open issue re. UUIDs is the syntax for internal links.
Some questions:
----
Should we include the publication ID, i.e. allow to link to
other pubs?
-1 from me, see below
----
Or should we exclude the publication ID and resolve the publication
based on the UUID (either by a lookup or by storing all docs from
all pubs in a single repository)?
-1 for the moment, but if we don't include the pub ID, we can always
upgrade to this without changing the internal links. I think this
can be done in 1.4.x.
----
Should we exclude the area?
+1 from me
----
Which protocol should we use?
IMO the relative form of the lenyadoc:/ protocol is appropriate:
lenyadoc:/<language>/<uuid>
I would like to change the order of the arguments, because then
it would be quite straightforward to make the language optional.
The old order isn't necessary anymore because the UUID can't
contain slashes.
lenyadoc:/<uuid>/<language>
lenyadoc:/<uuid>
It would have to be defined what to do when the language version
doesn't exist - either fail, or use an existing version, preferably
the default language version. IMO this has to be configurable, but
I don't know at which level.
Feel free to state your opinions. TIA!
-- 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] Link syntax
Posted by Josias Thöny <jo...@wyona.com>.
On Wed, 2006-08-23 at 09:50 +0200, Andreas Hartmann wrote:
> Hi Lenya devs,
>
> (I'm starting a new thread to keep the discussion focused on 1.4)
>
> The last open issue re. UUIDs is the syntax for internal links.
> Some questions:
>
> ----
>
> Should we include the publication ID, i.e. allow to link to
> other pubs?
>
> -1 from me, see below
>
> ----
>
> Or should we exclude the publication ID and resolve the publication
> based on the UUID (either by a lookup or by storing all docs from
> all pubs in a single repository)?
>
> -1 for the moment, but if we don't include the pub ID, we can always
> upgrade to this without changing the internal links. I think this
> can be done in 1.4.x.
>
> ----
>
> Should we exclude the area?
>
> +1 from me
+1 to exclude the area and the publication id from the link, therefore
treating links to other publications as external links.
>
> ----
>
> Which protocol should we use?
> IMO the relative form of the lenyadoc:/ protocol is appropriate:
>
> lenyadoc:/<language>/<uuid>
>
> I would like to change the order of the arguments, because then
> it would be quite straightforward to make the language optional.
> The old order isn't necessary anymore because the UUID can't
> contain slashes.
>
> lenyadoc:/<uuid>/<language>
> lenyadoc:/<uuid>
This syntax is fine for me.
Josias
>
> It would have to be defined what to do when the language version
> doesn't exist - either fail, or use an existing version, preferably
> the default language version. IMO this has to be configurable, but
> I don't know at which level.
>
>
> Feel free to state your opinions. TIA!
>
> -- Andreas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Link syntax
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> (I'm starting a new thread to keep the discussion focused on 1.4)
>
> The last open issue re. UUIDs is the syntax for internal links.
I would suggest to use something like:
href="urn:lenya:af9731b0-3385-11db-a98b-0800200c9a66:en:4"
which would be something like
href="urn:lenya:UUID:LANG:REVISION"
I think this should be valid according to
http://www.ietf.org/rfc/rfc2141.txt
WDYT?
Thanks
Michi
> Some questions:
>
> ----
>
> Should we include the publication ID, i.e. allow to link to
> other pubs?
>
> -1 from me, see below
>
> ----
>
> Or should we exclude the publication ID and resolve the publication
> based on the UUID (either by a lookup or by storing all docs from
> all pubs in a single repository)?
>
> -1 for the moment, but if we don't include the pub ID, we can always
> upgrade to this without changing the internal links. I think this
> can be done in 1.4.x.
>
> ----
>
> Should we exclude the area?
>
> +1 from me
>
> ----
>
> Which protocol should we use?
> IMO the relative form of the lenyadoc:/ protocol is appropriate:
>
> lenyadoc:/<language>/<uuid>
>
> I would like to change the order of the arguments, because then
> it would be quite straightforward to make the language optional.
> The old order isn't necessary anymore because the UUID can't
> contain slashes.
>
> lenyadoc:/<uuid>/<language>
> lenyadoc:/<uuid>
>
> It would have to be defined what to do when the language version
> doesn't exist - either fail, or use an existing version, preferably
> the default language version. IMO this has to be configurable, but
> I don't know at which level.
>
>
> Feel free to state your opinions. TIA!
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Link syntax
Posted by Andreas Hartmann <an...@apache.org>.
Joachim Wolfgang Kaltz wrote:
> Hi Andreas,
>
> Andreas Hartmann schrieb:
>> (...)
>> The last open issue re. UUIDs is the syntax for internal links.
>> Some questions:
>>
>> ----
>>
>> Should we include the publication ID, i.e. allow to link to
>> other pubs?
>>
>> -1 from me, see below
>>
>> ----
>>
>> Or should we exclude the publication ID and resolve the publication
>> based on the UUID (either by a lookup or by storing all docs from
>> all pubs in a single repository)?
>>
>> -1 for the moment, but if we don't include the pub ID, we can always
>> upgrade to this without changing the internal links. I think this
>> can be done in 1.4.x.
>
> It's not clear to me what you actually propose :)
What I meant is that we shouldn't include the publication ID in links,
even though this means that we can't link to other publications at the moment.
But since the UUID is theoretically sufficient to identify a document accross
publications, we can implement resolving links to other publications later.
[...]
>> It would have to be defined what to do when the language version
>> doesn't exist - either fail, or use an existing version, preferably
>> the default language version. IMO this has to be configurable, but
>> I don't know at which level.
>
> Right, but that's a separate issue, so for now we can just keep it as it
> is, no?
Yes, unless we want to include this configuration in the link URL.
-- 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] Link syntax
Posted by Joachim Wolfgang Kaltz <jo...@uni-duisburg-essen.de>.
Hi Andreas,
Andreas Hartmann schrieb:
> (...)
> The last open issue re. UUIDs is the syntax for internal links.
> Some questions:
>
> ----
>
> Should we include the publication ID, i.e. allow to link to
> other pubs?
>
> -1 from me, see below
>
> ----
>
> Or should we exclude the publication ID and resolve the publication
> based on the UUID (either by a lookup or by storing all docs from
> all pubs in a single repository)?
>
> -1 for the moment, but if we don't include the pub ID, we can always
> upgrade to this without changing the internal links. I think this
> can be done in 1.4.x.
It's not clear to me what you actually propose :)
Anyway, I am +1 to exclude the publication ID.
A link to another publication is not an internal link, in my opinion. It
should be treated as any external link (http://etc).
>
> ----
>
> Should we exclude the area?
>
> +1 from me
+1
>
> ----
>
> Which protocol should we use?
> IMO the relative form of the lenyadoc:/ protocol is appropriate:
>
> lenyadoc:/<language>/<uuid>
>
> I would like to change the order of the arguments, because then
> it would be quite straightforward to make the language optional.
> The old order isn't necessary anymore because the UUID can't
> contain slashes.
>
> lenyadoc:/<uuid>/<language>
> lenyadoc:/<uuid>
+1
>
> It would have to be defined what to do when the language version
> doesn't exist - either fail, or use an existing version, preferably
> the default language version. IMO this has to be configurable, but
> I don't know at which level.
Right, but that's a separate issue, so for now we can just keep it as it
is, no?
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Link syntax
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
[...]
> Which protocol should we use?
> IMO the relative form of the lenyadoc:/ protocol is appropriate:
>
> lenyadoc:/<language>/<uuid>
>
> I would like to change the order of the arguments, because then
> it would be quite straightforward to make the language optional.
> The old order isn't necessary anymore because the UUID can't
> contain slashes.
>
> lenyadoc:/<uuid>/<language>
> lenyadoc:/<uuid>
I just noticed that it might make sense to use a different delimiter,
for instance a colon:
- With the slash as separator, an absolute URL is created if the
UUID is accidentally an empty string (lenyadoc://en)
- If we don't use the slash, we could make the UUID optional as well
(lenyadoc:/:en). For instance, in a customer project, we had to
display the English version on French news pages. This would be
quite easy with this syntax:
<ci:include src="lenyadoc:/:en"/>
-- 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] Link syntax
Posted by Doug Chestnut <dh...@virginia.edu>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> (I'm starting a new thread to keep the discussion focused on 1.4)
>
> The last open issue re. UUIDs is the syntax for internal links.
> Some questions:
>
> ----
>
> Should we include the publication ID, i.e. allow to link to
> other pubs?
>
> -1 from me, see below
-1 from me as well
>
> ----
>
> Or should we exclude the publication ID and resolve the publication
> based on the UUID (either by a lookup or by storing all docs from
> all pubs in a single repository)?
>
> -1 for the moment, but if we don't include the pub ID, we can always
> upgrade to this without changing the internal links. I think this
> can be done in 1.4.x.
+1, but after a release :)
>
> ----
>
> Should we exclude the area?
>
> +1 from me
+1
>
> ----
>
> Which protocol should we use?
> IMO the relative form of the lenyadoc:/ protocol is appropriate:
>
> lenyadoc:/<language>/<uuid>
+0
>
> I would like to change the order of the arguments, because then
> it would be quite straightforward to make the language optional.
> The old order isn't necessary anymore because the UUID can't
> contain slashes.
>
> lenyadoc:/<uuid>/<language>
> lenyadoc:/<uuid>
I like the lenyadoc:/:en (colon) idea from your later email
>
> It would have to be defined what to do when the language version
> doesn't exist - either fail, or use an existing version, preferably
> the default language version. IMO this has to be configurable, but
> I don't know at which level.
>
>
> Feel free to state your opinions. TIA!
>
> -- Andreas
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Link syntax
Posted by so...@apache.org.
On 8/25/06, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@apache.org wrote:
> > 1.4 has two protocols for accessing content? XMAP developers must
> > decide which is appropriate for each match? Sometimes language is
> > required, but sometimes it is optional? <map:match
> > pattern="/mypipeline/**"> must know whether ** is an ID or a UNID?
> I think it should be stated explicitely how you address a document.
> I don't like the approach of allowing UUIDs and site structure paths
> in the same protocol.
Both Authoring and Live Modules call DocumentTypeModules to retrieve
the XML. They pass the current URL. Authring uses UUIDs. Live uses
IDs. The DocumentTypeModule contains:
<map:match pattern="/doctype/**">
<map:generate src="content:/(1)">
Lenya should make everything as easy as possible. If different
protocols are required based on the calling method, more pipelines are
needed. More pipelines = more work = not as easy as possible.
Besides, it is easy for one protocol to handle both cases. If there
are no slashes after the protocol specification, try to retrieve using
it is a UUID. If it does not exist, or if there were slashes, try
using it as an ID.
> > If defaultlanguage is not by Resource, every page will default to the
> > default language.
> Hmm, what's wrong with that?
> > Everybody will set the default language to "xx" so
> > only items in that non-existent language will use a default. Why make
> > people use workarounds?
> Sorry, I don't understand that ...
> Why should someone want to set the default language to "xx"?
There is a multi-language pub. Each language should only show each
Resource if the Translation exists. The Publication's defaultlanguage
is "en". If the request does not contain a language, "en" is used.
We then retrieve the Resource.
With Resource-specific default languages, if the Resource does not
contain the specified translation, it can fail.
Without Resource-specific default languages, if the Resource does not
contain the specified translation, it returns the defaultlanguage
Translation. But if the specified Translation does not exist, you do
not want it to appear. You still need a defaultlanguage so images
only need one Translation, so as a workaround, you create a fake
language "xx" for use as the defaultlanguage. The workaround has
side-effects, such as each Resource having an extra language on its
language choice menu.
The defaultlanguage of a pub should only be used if no language is
specified. A Resource-specific defaultlanguage allows some Resources
to have many Translations with failure if the requested one does not
exist, and other Resources with a default Translation.
Again, it was easy to add the defaultlanguage attribute at the
Resource level (above the Translation level:
Resource/Translation/Revision).
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Link syntax
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@apache.org wrote:
[...]
> 1.4 has two protocols for accessing content? XMAP developers must
> decide which is appropriate for each match? Sometimes language is
> required, but sometimes it is optional? <map:match
> pattern="/mypipeline/**"> must know whether ** is an ID or a UNID?
>
> No comment. I cannot think of anything nice to say.
I think it should be stated explicitely how you address a document.
I don't like the approach of allowing UUIDs and site structure paths
in the same protocol.
[...]
> If defaultlanguage is not by Resource, every page will default to the
> default language.
Hmm, what's wrong with that?
> Everybody will set the default language to "xx" so
> only items in that non-existent language will use a default. Why make
> people use workarounds?
Sorry, I don't understand that ...
Why should someone want to set the default language to "xx"?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Link syntax
Posted by so...@apache.org.
On 8/24/06, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@apache.org wrote:
> > This was solved for 1.3:
> > content:/resourceUNID
> > content:/resourceUNID_language
> > content:/resourceUNID!revision
> Good point, we could use the revision-based syntax in 1.4 as well.
>
> > content:/resourceUNID_language!revision
> > resourceUNID is the UUID.
> > language and revision are optional. language defaults to the current
> > language. revision defaults to the revision marked "live" for the
> > Translation.
> > There are also variations for using a Resource's ID from the
> > hierarchy of a Structure. XMAPs can access Resources without
> > translating the path to the UNID.
> > content:/1234
> > content:/live/parentDocumentInLiveStructure/documentID
> > both access the same Resource.
>
> In 1.4, the site:/ protocol serves this purpose
> (http://lenya.apache.org/docs/1_4/reference/protocols/site.html)
>
> But I just noticed that the site:/ protocol doesn't allow to
> omit the language, I guess the syntax should be changed.
1.4 has two protocols for accessing content? XMAP developers must
decide which is appropriate for each match? Sometimes language is
required, but sometimes it is optional? <map:match
pattern="/mypipeline/**"> must know whether ** is an ID or a UNID?
No comment. I cannot think of anything nice to say.
> > From my experience, "live" uses IDs (from URLs generated for visitors)
> > and "edit" uses UNIDs (from URLs generated by maintenance screens).
> > Using underscore '_' and exclamation mark '!' as separators means the
> > same protocol can serve both IDs and UNIDs.
> >
> > ---
> > Each Resource can have a "defaultlanguage" parameter. If the
> > specified language does not exist, defaultlanguage is also tried.
> > This is very useful with images, so an image is maintained for only
> > one Translation, and that Translation is used for every language.
>
> Should we allow a default-language parameter for each document in 1.4?
> This is another case where translation-independent meta data would
> come in handy. Or is the per-publication parameter sufficient?
> What do the others think?
If defaultlanguage is not by Resource, every page will default to the
default language. Everybody will set the default language to "xx" so
only items in that non-existent language will use a default. Why make
people use workarounds?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Link syntax
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@apache.org wrote:
[...]
> This was solved for 1.3:
> content:/resourceUNID
> content:/resourceUNID_language
> content:/resourceUNID!revision
Good point, we could use the revision-based syntax in 1.4 as well.
> content:/resourceUNID_language!revision
>
> resourceUNID is the UUID.
> language and revision are optional. language defaults to the current
> language. revision defaults to the revision marked "live" for the
> Translation.
>
> There are also variations for using a Resource's ID from the
> hierarchy of a Structure. XMAPs can access Resources without
> translating the path to the UNID.
> content:/1234
> content:/live/parentDocumentInLiveStructure/documentID
> both access the same Resource.
In 1.4, the site:/ protocol serves this purpose
(http://lenya.apache.org/docs/1_4/reference/protocols/site.html)
But I just noticed that the site:/ protocol doesn't allow to
omit the language, I guess the syntax should be changed.
> From my experience, "live" uses IDs (from URLs generated for visitors)
> and "edit" uses UNIDs (from URLs generated by maintenance screens).
> Using underscore '_' and exclamation mark '!' as separators means the
> same protocol can serve both IDs and UNIDs.
>
> ---
> Each Resource can have a "defaultlanguage" parameter. If the
> specified language does not exist, defaultlanguage is also tried.
Should we allow a default-language parameter for each document in 1.4?
This is another case where translation-independent meta data would
come in handy. Or is the per-publication parameter sufficient?
What do the others think?
[...]
> Accessing other Publications is better solved by using the cocoon:
> protocol and a Pipeline in the other pub that returns XML. That
> covers whether the Publications are on the same server or different
> servers, and respects the security of each Publication.
Good point, we have to consider this in 1.4.
IMO the repository layer should handle access control, so that reading
a document via the lenyadoc:/ protocol is only allowed if you have
sufficient permissions. Same username doesn't count as same user if
you access a different publication. But this is something for a later
release.
Thanks for your comments!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] Link syntax
Posted by so...@apache.org.
On 8/23/06, Andreas Hartmann <an...@apache.org> wrote:
> The last open issue re. UUIDs is the syntax for internal links.
> Should we include the publication ID, i.e. allow to link to
> other pubs?
> -1 from me, see below
> ----
> Or should we exclude the publication ID and resolve the publication
> based on the UUID (either by a lookup or by storing all docs from
> all pubs in a single repository)?
>
> -1 for the moment, but if we don't include the pub ID, we can always
> upgrade to this without changing the internal links. I think this
> can be done in 1.4.x.
> ----
> Should we exclude the area?
> +1 from me
> ----
> Which protocol should we use?
> IMO the relative form of the lenyadoc:/ protocol is appropriate:
> lenyadoc:/<language>/<uuid>
>
> I would like to change the order of the arguments, because then
> it would be quite straightforward to make the language optional.
> The old order isn't necessary anymore because the UUID can't
> contain slashes.
>
> lenyadoc:/<uuid>/<language>
> lenyadoc:/<uuid>
>
> It would have to be defined what to do when the language version
> doesn't exist - either fail, or use an existing version, preferably
> the default language version. IMO this has to be configurable, but
> I don't know at which level.
This was solved for 1.3:
content:/resourceUNID
content:/resourceUNID_language
content:/resourceUNID!revision
content:/resourceUNID_language!revision
resourceUNID is the UUID.
language and revision are optional. language defaults to the current
language. revision defaults to the revision marked "live" for the
Translation.
There are also variations for using a Resource's ID from the
hierarchy of a Structure. XMAPs can access Resources without
translating the path to the UNID.
content:/1234
content:/live/parentDocumentInLiveStructure/documentID
both access the same Resource.
>From my experience, "live" uses IDs (from URLs generated for visitors)
and "edit" uses UNIDs (from URLs generated by maintenance screens).
Using underscore '_' and exclamation mark '!' as separators means the
same protocol can serve both IDs and UNIDs.
---
Each Resource can have a "defaultlanguage" parameter. If the
specified language does not exist, defaultlanguage is also tried.
Examples:
1. Request "de", no defaultlanguage. Return "de" if it exists, otherwise fail.
2. Request "de", defaultlanguage="en". Return "de" if it exists, else
return "en" if it exists, otherwise fail.
This is very useful with images, so an image is maintained for only
one Translation, and that Translation is used for every language.
---
Accessing other Publications is better solved by using the cocoon:
protocol and a Pipeline in the other pub that returns XML. That
covers whether the Publications are on the same server or different
servers, and respects the security of each Publication.
Adding a method that allows access to "Very Confidential Document"
from another pub could be dangerous, since the Users and Groups may be
different. Someone could be in the Admin Group in this pub, but not
for the other pub, and access confidential information if the Resource
allows access for the Admin Group.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org