cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Wagner" <dwag...@sa.kevric.com>
Subject RE: Small note on sitemap configuration
Date Fri, 02 Jun 2000 19:51:54 GMT
Some thoughts on the sitemap, resources, URIs.  (Thoughts on matching
may follow next week.)

Well, I did a bit of research on the definition of a resource and how
it relates to the syntax of its URI/RNL/URN.  A resource can be
anything.  A URI may identify anything.  An individual thing may have
more than one URI.  The same URI may identify different things
dependant on other (even random) factors.  (Consider hitting the URI
for headline news or a fortune cookie servlet full of Random
Thoughts.)

Consider the following simplified case of a document available in one
language and its translation in another.  Note Cocoon will _not_ be
able to actually generate one from the other anytime in the near
future.

(Relative paths have the arbitrary xml:base="http://test.net/")

mydocument_en and mydocument_it are different resources.  I think we
can agree on that.  So, mydocument?lang=en and mydocument?lang=it are
different resources.  Maybe.  I cannot determine from the references
if the querystring is considered to be part of the identifier or not.
However, it seems valuable to consider it so.

Now, with content negotiation a request to the URI
http://test.net/mydocument may return either mydocument_en or
mydocument_it.  For users this may depend on browser setup, though
they should have the option to request documents in other languages
without reconfiguring the browser.  In other words, most HTTP info
should be overridable, especially since content negotiation is not
well implemented.  (I personally want SVG right now over GIF and PNG
whenever possible.  The Adobe plugin is very nice.)

If you wanted to you could also assign mydocument_en to
http://test.net/alsk/fl/3s3k2jd#fl and mydocument_it to
http://bar.net/kk3si5ii.s, if you really wanted to do so, so long as
Cocoon could be able to determine what to deliver based on these
requests: to map the URI to the resource.  The URI is arbitrary, and
may (though it need not) reflect a hierarchical structure.  For
simplicity, compatibility, and human-readability, it is a Good Thing
to use a hierarchical structure seperated by slashes, with a hash
before a 'document fragment' and a question mark before the 'query'.

XPointer defines a few means of interpreting the 'document fragment'
and leaves plenty of other variations open.

The 'query' works well for making name-value pairs, but interpreting
these as 'state', 'variables', 'parameters', or whatever is entirely
up to the application.

Now for a question concerning the seperation of concerns.  Someone
with blurry vision and a nice big screen wants the following resource:
mydocument?fontsize=24pt.  Cocoon can (easily) generate this requested
resource from the existing mydocument_it (or mydocument_en, as
negotiated).  In the grand scheme of things this is a different
resource from mydocument?lang=it&fontsize=24pt (which will always be
large and Italian, no matter the browser setting).  It is also
different from mydocument?format=wml and from mydocument?format=pdf
(which could be a synonym for mydocument.pdf), and from
mydocument?browser=Amaya, even though the identical, untransformed,
source resource may be delivered to any or even all these different
URIs (say, when load>10000).

So, given only the request (URI + HTTP info), can the sitemap
determine the pipeline?.  Cocoon user state info and the state of the
world at the time of the request probably needs to be factored in as
well, though this will be difficult.

Consider the following request:
http://headlines.net/today?searchfor=apache
Assume there is a servlet providing the headlines and another
filtering the search, while cocoon provides the rest of the page.  If
the search returns no results (because of the state of the world at
the time of request), something Cocoon may not know until the process
is far down the pipe, it should instead respond with a redirect to (or
simply provide instead) the 'Advanced Search Page', or somesuch.

So, how much logic is needed in the sitemap?  Shoud parts of the HTTP
and URI map to different components?  Should some set user state or
variables?  The definition Cocoon uses for resource is important here,
though I suspect it will not be possible to seperate concerns in the
URI, it may be possible to segregate them.

I hope this helps the discussion, though I do expect disagreement on
the definitions of resource and URI.  -David

P.S.  If I've gotten anything wrong about how Cocoon works, please let
me know.


Mime
View raw message