[dsdl-discuss] Re: What is the best way to simulate substitution groups betweenmodules?

Hi Rick,

Le jeudi 17 août 2006 à 16:47 +1000, Rick Jelliffe a écrit :
> Eric van der Vlist said:
>
> > I am not sure I understand what you mean by "grammars with other
> > namespaces". Grammars (and patterns) do not belong to a namespace in
> > RELAX NG! The notion of namespace for RELAX NG is pretty much limited to
> > restricting name classes (and resolving QNames).
>
> Is that right? I looked in the ISO and OASIS specs, for RELAX NG and the
> compact syntax, and I looked at your book (so great to have it online) and
> at that article you mentioned.
>
> But I couldn't see anything about the scoping or visibility of pattern
> names: all the examples I have seen have been the simple case where either
> one schema has an element from another namespace or where inclusion is
> used for the same namespace.

If you look at the description of how the ns attribute is handled during
simplification (7.10 in the ISO spec), you'll see that this attribute is
kept only in name classes...

> But does it really mean that if I have three schemas in different
> namespaces, A B and C, and schema A includes both schema B and C, and
> schema B and C happen to have patterns with the same name, that it is an
> error?

Yes. If you want to avoid that, you need to use externalRef (but, of
course, externalRef and include are very different beasts).

A way to cope with this is probably to add a distinctive prefix or
suffix (such as my.foo or foo.my) to your pattern names.

> That seems to undo the entire reason for having namespaces in the first
> place, to allow modularity.

Sure, but the namespace rec explicitly mentions the consequences only
for elements and attributes and not for RNG patterns :) ...

I guess that there are two different ways of looking at the issue. Like
W3C XML Schema you can extend namespaces to also deal with datatypes but
you can also consider that they only apply to elements and attributes.

Note that ISO Schematron follows the "RELAX NG way" of handling
namespaces and that you would have the same kind of issues with modular
Schematron schemas.

> I suppose that is why NVRL is necessary.

That can be another reason why it is necessary even though this isn't
the most common use case.

> > I have tried to cover all that stuff in my book:
> > http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-2.html
> >
> >> And it is made more complicated by the fact that the elements being
> >> added
> >> in the substitution group have a type belonging to the original
> >> substitution head.
> >>
> >> Any ideas?
> >
> > Can't what I have suggested after an exchange on XML-DEV help?
> >
> > http://eric.van-der-vlist.com/blog/2814_RELAX_NG_and_W3C_XML_Schema_compared_%28continued%29.item
>
> That material was really handy, but it would be great to have some
> explicit statement like "Patterns cannot be addressed by their schema
> document or grammar or their grammar's target namespace or any other
> mechanism.

That's worse than that: RELAX NG has no notion of target namespace...

> Consequently, for schemas to be used for namespaces that are to
> be used as modules by other schemas, take care to use pattern names that
> are not likely to have name clashes."

Sure. That seemed so obvious to me that I had never thought it required
to be written down :) !

Thanks for making me understand that this isn't the case...

Eric

-- 
GPG-PGP: 2A528005
Freelance consulting and training.
                                            http://dyomedea.com/english/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
(ISO) RELAX NG   ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)