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>
where any of the components (uuid>, <language> <area> <revision>
<pub-id>) are optional, i.e. everything that is not specified is derived
from the current page envelope information.
please comment - your insight is greatly appreciated.
for those who have not followed the previous posts on this topic, a
short summary:
[the problem]
at the moment, lenya uses a nice, uuid-based storage backend that allows
site restructuring without having to shuffle files around, because
content files and structure (i.e. sitetree.xml) are decoupled.
but we currently have no way of defining links to lenya documents in
this fashion - for linking, we still use the sitetree-dependent document
path, which will break when users restructure their sites (i.e. move
pages around).
[discussion]
the primary identifier of a document is the UUID, so this has to become
the main part of the link syntax. but to further pinpoint the desired
resource, we also need a way to optionally specify the language version,
the area and the revision.
if, in the future, cross-publication linking were to be supported, it
might also be helpful to spell out the publication id for faster
retrieval, even though in theory a UUID lookup mechanism could work
without explicit knowledge of the publication id due to the global
uniqueness of the uuids.
using the traditional approach of putting a number of slash-separated
"parameters" into a standard URL has a number of disadvantages:
* it is very hard to read and easy to get wrong
* we might want different types of "relative" links, for example:
* specify only the language -> i want another language version of the
current document
* specify only the area (= same doc, same lang)
* specify only the uuid (= same lang, same area)
* specify only a revision (= same doc, same lang, same area, other
version)
generally, you could specify as few or many attributes as you like,
and the others would be gleaned from the page envelope. with the
current positional parameter scheme, we have already seen a
rather hackish quick fix for relative linking that leads to
constructs such as "lenyadoc://{1}/{2}/{4}/{3}".
by borrowing the GET parameter syntax from http requests, we gain a
truly multi-dimensional parameter model where arbitrary parts can be
left unspecified, and we get a self-documenting syntax with named
parameters and no magic position-based semantics as in
lenyadoc://something/somethingelse/foo/bar
it had been proposed to re-use the lenyadoc semantics to specify
internal links, but we have decided not to, for two reasons: lenyadoc
uses positional parameters with all disadvantages mentioned before, and
the link references are never actually fed to a source factory, but
instead handled by a link rewriter mechanism. so it was considered
misleading to use the semantics of an existing source factory for a
mechanism that is totally independent of said source factory.
[future improvements]
however, it might be interesting to consider implementing a real
lenya-document: source factory in the near future and use it instead of
the current lenyadoc:// scheme, so as to benefit from the multiple ways
of relative linking and the self-documenting named parameters. the old
lenyadoc: factory could then be deprecated and gradually replaced, to
avoid disruptive changes while 1.4 is stabilizing.
[musings]
before implementing, we should probably get a clear idea of whether the
proposed scheme is a Uniform Resource Name, a Uniform Resource Locator,
or a Uniform Resource Identifier, and check the current proposal against
relevant rfcs pertaining to those uniform resource gizmos, in order to
build on existing, proven concepts and to avoid introducing something
that might become overly idiosyncratic in the near future.
your comments on this are especially appreciated.
regards,
jörn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
