From: "Sylvain Wallez" <[EMAIL PROTECTED]>
> Christian Haul wrote:
>
> >On 28.May.2002 -- 04:01 PM, Christian Haul wrote:
> >
> >>Now someone more knowledgeable of the sitemap variables'
> >>implementation can tackle the suggestion. :-)
> >>
> >>To followup on Nicola Ken's comment, we could have a sitemap: pseudo
> >>protocol for variables as we know them now and a module: pseudo
> >>protocol for input modules.
> >>
> >
> >Should have been
> >
> > Like
> >
> > <map:generate src="{sitemap:1}"/>
> > <!-- sitemap variable named "1" -->
> >
> > <map:generate src="{module:request-param:name}"/>
> > <!-- value obtained from input module "request-param" for an attribute
named "name" -->
> >
> > <map:generate src="file.xml"/>
> > <!-- value "file.xml" -->
> >
> > <map:generate src="{cocoon://file.xml}"/>
> > <!-- value obtained from other pipeline -->
> >
> > <map:generate src="cocoon://file.xml"/>
> > <!-- value "cocoon://file.xml" -->
> >
> > Chris.
> >
>
> Sorry for the delay : this subject is of great interest to me but I had
> some more-than-urgent work.
>
> I think you're going too far, for two reasons :
> - you introduce heavy back-incompatibility issues by requiring all
> variables to be prefixed (i.e. the "sitemap" prefix)
yes, this is a problem.
> - you mix InputModules and Sources, which I consider, as I previously
> said, different beasts.
I would like to see a URI being used, so that we have a unifor way of
accessing "stuff".
I know that these uris would not define streams, but neither do the URIs
used to define dtds.
Using uris, we could still keep current behaviour ("param" or "../../param")
and still extend it.
> My opinion is that protocol-based variable substitution should be
> restricted to *InputModules only*, as what we want to substitute is a
> single character string, and not a data-stream produced by a Source.
>
> Sure, we can imagine a Source that produces a single element whose child
> text node can be used to substitute the variable. But for this (IMO
> rather rare) case, we could write a SourceInputModule.
URIs define locations, and AFAIK don't really have the notion of what they
reference.
"URI Uniform Resource Identifier. The generic set of all names/addresses
that are short strings that refer to resources.
"http://www.w3c.org/Addressing/
But as for keeping the two *implementations* and usage scenarios separate, I
agree.
We just need to make our scheme and keep consistent naming.
> We also have to define a syntax that distinguishes "classical" sitemap
> variables from module-defined variables that is both readable and
> reduces the likelyness of backward-incompatibilities.
>
> I see several possibilities :
>
> 1. {module:parameter} : prefix parameter name by the module name.
> Very simple, but the more likely to lead to imcompatibilities.
> 2. {/module:parameter} : same as above, but attach module-defined
> variables to the root of the variable tree. Unlikely to lead to
> imcompatibilities because the "/" is already used to travel up the
> hierarchy.
> 3. {module://parameter} : more URL-ish, but IMO leads to a confusion
> with sources, which I would like to avoid.
Of these I would prefer (3) for consistency, but agree that it can cause
confusion.
You write module://parameter, but a module is not a "protocol".
In http://www.ietf.org/rfc/rfc2718.txt
"
2.2.3 Definition of non-protocol URL schemes
In some cases, URL schemes do not have particular network
protocols associated with them, because their use is limited to
contexts where the access method is understood. This is the case,
for example, with the "cid" and "mid" URL schemes. For these URL
schemes, the specification should describe the notation of the
scheme and a complete mapping of the locator from its source.
"
This means that URLs, and also URIS (superset), are intended from the start
also for things that are not sources.
In http://www.ietf.org/rfc/rfc2396.txt we have a detailed description.
Being a module is a scheme (for URL it's usually a "protocol"), I would
suggest
module://moduletouse/path/to/param?moduleattr=value
in fact:
"
3. URI Syntactic Components
The URI syntax is dependent upon the scheme. In general, absolute
URI are written as follows:
<scheme>:<scheme-specific-part>
[...]
This "generic URI" syntax consists of a sequence of four main components:
<scheme>://<authority><path>?<query>
each of which, except <scheme>, may be absent from a particular URI.
"
"
3.2. Authority Component
Many URI schemes include a top hierarchical element for a naming
authority, such that the namespace defined by the remainder of the
URI is governed by that authority. This authority component is
typically defined by an Internet-based server or a scheme-specific
registry of naming authorities.
"
The authority is the module to use.
This way, having module:// to start these URIs, we eliminate the confusion
problem.
> My personal preference goes to (2), which would change your examples to :
>
> <map:generate src="{1}"/>
> <!-- sitemap variable named "1" -->
>
> <map:generate src="{/request-param:name}"/>
> <!-- value obtained from input module "request-param" for an attribute
named "name" -->
>
> <map:generate src="file.xml"/>
> <!-- value "file.xml" -->
>
> <map:generate src="{source:cocoon://file.xml}"/>
> <!-- value obtained from other pipeline : the "source" module fetches the
> text node of a single-element document -->
>
> <map:generate src="cocoon://file.xml"/>
> <!-- value "cocoon://file.xml" -->
>
>
> As for sitemap parameters currently under discussion,
> their could be identified either as non-prefixed root
> variables, i.e. "{/skin}", or by a "sitemap" pseudo-module
> , i.e. "{/sitemap:skin}".
Since the "module:" scheme returns a parameter, it's sensibly that the
sitemap context is seen exactly as the request, response, session, etc.
In fact it's a per-invocation session ;-)
> What do you think ?
>
> I also volunteer to implement this (I should have some time for it
starting at the end of next week).
:-D
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
