[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
