Bug 43813

a quick grep indicates that bxe is the only user of
{resource-type:httpSchemaUri}, and that {resource-type:schemaUri} is not used at
all.
should we just deprecate both and require all doctypes to provide a
"/modules/<resourceType>/schema.rng" in their sitemaps?

The problem is that a module can contain more than one resource type. For
instance the forrest module will contain resource types for "normal", FAQ,
changes, ... documents.

(In reply to comment #2)
> The problem is that a module can contain more than one resource type. For
> instance the forrest module will contain resource types for "normal", FAQ,
> changes, ... documents.

but is that worth it? wouldn't it simplify things a lot if we mandate one
doctype == one module? afaik multiple doctypes per module are not widely used,
and splitting them would be trivial.
then we could get rid of some code and replace another layer of configuration
with convention. the fallback resolver hack is really frightful, and totally
unnecessary imho given that we could just as well handle the stuff in sitemaps,
where all the glorious resolvers are available without limitations and hacks.
wdot?

that said, i'd also like to re-discuss the formats post 2.0. do we really need
formats as a configurable with a corresponding input module, or could we just
use matchers in the resource type module sitemaps and define these as an API?
reduces overhead, gets rid of indirection, makes stuff more self-explanatory.

for now, i have removed the context from the module. this implies you need to
wrap it in a {proxy:} call. not very logical (httpSchemaUri sounds like it
delivers a complete http://.... uri), but works for now. i'm still thinking this
should go altogether.

andreas, if you think multiple doctypes per module are important, let's implement
/modules/<moduleName>/schemas/<resourceTypeName>.rng in every doctype module
sitemap and get rid of the configuration and input module. wdyt?
(i'm not fundamentally opposed to an input module in itself, i just think
second-guessing the meaning of fallback:// is not a concern of such a module -
if it can be avoided, i could live with it. although it's configuration instead
of convention.)

(In reply to comment #4)

> andreas, if you think multiple doctypes per module are important, let's implement
> /modules/<moduleName>/schemas/<resourceTypeName>.rng in every doctype module
> sitemap and get rid of the configuration and input module. wdyt?

That would be very convenient, but the problem is that we don't know which
module the resource type is provided by ... Maybe we could introduce a
convention for resource type names:

  {module} if only one resource type is provided by the module
  {module}.{resourceType} if multiple resource types are provided

The module name could be extracted by the resource type module:

  {resource-type:module:{doc-info:....:resourceType}}

But then it's only a small step to the situation which we have now.

But we could go one step further and require the following syntax for resource
type names:

  {module}.{resourceTypeName}

This could be matched in the sitemap:

  .../*.*/...

<map:generate src="{proxy:/modules/{1}/schemas/{2}.rng}"/>

Unfortunately, all document meta data would have to be updated when the names of
the existing resource types change.

OTOH, this means that we would address the module using its short name, which
ultimately renders the module package useless.

If we support both {resourceType} and {module}.{resourceType} we would have to
provide two pipelines:

<map:match pattern=".../*.*/...">
  <map:generate src="{proxy:/modules/{1}/schemas/{2}.rng}"/>

<map:match pattern=".../*/...">
  <map:generate src="{proxy:/modules/{1}/schemas/{1}.rng}"/>

IMO this is acceptable.