Hunsberger, Peter wrote:
>>>I can think of many use cases where I might
>>>want to parcel out handling of a portion of a site to some other group,
>>> but
>>>still continue processing a request if the other groups sitemap did not
>>>handle it.
>>
>>Please share them with us.
>
>
> The general use case is where a web site has to handle non-hierarchical
> structure. For example cross functional reporting. You may want to parcel
> out handling of area "x" to one group and of area "y" to another. Since
> there is an intersection of responsibilities a third requirement to also
> handle those cases of the form "xy" (or "yx") Currently you can't do this
> in a general fashion with sub-sitemaps.
>
> As a specific use case consider sections within a departments all
> contributing to the same web site. Each group is authorized to update a
> subdirectory containing their own sitemap and handle content within their
> own area. Suppose the department has a statistics section responsible for
> handling requests for data crunching. Suppose the department also has it's
> own IT group responsible for handling infrastructure issues (new PC's etc.)
> The first group may have a sitemap matching the pattern "stats*", the second
> group might have a pattern matching "it*".
>
> In our case, the stats group also mostly handles their own infrastructure,
> but not always (historical and political reasons). Similarly, some requests
> for stuff that looks like stats isn't (requests for statistics on IT
> infrastructure). It would be good if requests like "stats*/it*" could first
> be matched against the stats department and then against the IT departments
> pages. Similarly, it would be good if requests like "it*/stats*" could be
> first matched against the IT pages then the stats pages. (Of course the
> stats departments also produces stats about their own IT infrastructure.)
>
> The point is, that since these two sections are working independently of
> each other we don't necessarily know how they will code their URL's and we
> want each to have a shot at resolving any given URL. Yes, given such a
> scheme, there could be cases where one section accidentally intercepts
> another sections URL (dependant on who comes first in the master sitemap),
> but those can be resolved through negotiation between the two sections (and
> the precedence rules would still be well understood).
>
> Is this necessary? Probably not.
In fact, in the above scenario it isn't.
> Is there any reason not to allow it?
> Probably not.
Let me disagree.
A sitemap is a *contract*.
It defines the URI space of your site, and URIs are hierarchical in nature.
If you define the URI space *outside* of the sitemap ("but those can be
resolved through negotiation between the two sections") you are
effectively reducing the usefulness of the sitemap.
Since splitting URIs between groups is a rule, ie a *contract*, on the
URI space, it should be evident in the sitemap itself and defined
*before* the control is delegated to the subsitemaps, because it should
be negotiated between the parties *before* they start adding pages and
potentially stepping on their toes.
Now, given that your groups don't want to tread on each other when
working, simply define the spaces they can manage in the main sitemap
and the problem is elegantly solved.
"we don't necessarily know how they will code their URL's and we
want each to have a shot at resolving any given URL."
Exactly what I want to avoid.
URI spaces must be well crafted up front, and possibly self-describing
and easy to understand.
--
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]
