Joern Nettingsmeier wrote: > > > Andreas Hartmann wrote: >> Hi Jörn, >> >> Joern Nettingsmeier schrieb: >>> here's a proposal for a new lenya document reference syntax, to be used >>> for internal links, assets and image inclusions: >>> >>> lenya-document:<uuid>?lang=<language>&area=<area>&rev=<revision>&pub=<pub-id> >>> >> >> unfortunately, there is a problem with this syntax: >> It is not possible to distinguish lenya-document parameters from >> request parameters. >> >> For instance, consider an internal link to a usecase-document >> page. This would lead to a conflict if the usecase also requires >> an "area" parameter (e.g., a "show area version" usecase could be >> invoked in the authoring area on a live document). >> >> Possible solutions: >> >> >> - use a different delimiter for lenya-document parameters >> >> lenya-document:uuid=...:lang=...:area=authoring?area=live >> >> >> - prefix the lenya-document parameters >> (would be quite verbose) >> >> >> - add another delimiter after the lenya-document parameters >> >> lenya-document:<uuid>?area=authoring?area=live >> >> I guess this doesn't conform to the URI syntax, though. >> >> >> - use a different syntax for lenya-document parameters, e.g. >> >> lenya-document:<uuid>[EMAIL PROTECTED]'authoring']?area=live >> >> This probably doesn't conform to the URI syntax either. > > > very important point! > > i don't like the non-conformant syntaxes, if only because it means we > must write a custom parser (which is definitely non-trivial for unicode > - recall Microsoft's cherished "Code Red" fuck-up), and we should really > abstain from ad-hoc string munging in this implementation. > > 2 solutions come to mind: > reserve a prefix namespace like "lenya-..." and use > "?lenya-area=..." and so on, or do nothing and let people fix their > custom query params. > for obvious reasons, i prefer the former solution, even if it makes the > queries more verbose. > I would also prefer the lenya prefix for the lenya-document parameters. That seems the most obvious solution to me. BTW, would it even be possible for the people to fix all query params without touching core files? Anyway the second solution is not a very user friendly one :-(
[ ... ] Jann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
