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=&
lt;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://///".
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: dev-unsubscribe lenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org
|