On 8/23/06, Andreas Hartmann <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
