cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: RELAXNG grammar for sitemap
Date Fri, 25 Oct 2002 04:24:16 GMT
Colin Paul Adams wrote:
> I have used the rng tool to generate a grammar for sitemap.xmap, from
> sitemap-v04.dtd (patched version). I did this just to see how
> difficult it was. As expected, it did not work automatically - I had
> the same problem with dtd2xsd when trying to generate a WXS grammar.

I am not sure which tool you refer to. I had no problems
at all when using DTDinst. See the URL for Jing and DTDinst
in the previous discussion on this topic:
 Re: DTD v. WXS v. Schematron v. RelaxNG

> The problem is the DTD effectively has two namespaces - the map:
> namespace and the global namespace. I guess as DTDs do not support
> namespaces, the conversion tools do not attempt to cope with this.

I presume that the draft sitemap DTD is using a workaround
for the namespace lack, by having explicit element names which
contain the "map:" prefix, e.g. <!ELEMENT map:components ...
This workaround is then reflected in the generated RNG.
Is that what you are referring to with your next statement?

> Still, I was able to systematically correct the grammar, so I could
> automate the process with an emacs macro or some such.
> The generated grammar is equivalent to the DTD grammar, and as such
> fairly loose. I could go on to express the rules better now
> (e.g. map:components should have at most one child of each type, but
> in any order).

I gather that you are suggesting to maintain a canonical
RNG grammar, which we use for system validation. Then from
that canonical RNG we can generate a WXS schema that can be
used by any XML editors that cannot use RNG. That sounds like
the way to go.

We should compare the two RNG grammars that are generated
from sitemap-v04.dtd to decide which one to base any further
work upon. Or perhaps we should really write it from scratch,
just using the generated ones for guidance.

> Then perhaps write an ant validation task, or maybe
> runtime validation through an coccon.xconf option?

Did you see the demonstration that i provided in the
abovementioned thread? It provides an Ant task for
build-time validation. Also Pete Royal followed up
with mention about validation of Configuration objects
via Avalon soon.

To unsubscribe, e-mail:
For additional commands, email:

View raw message