OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Avoiding name collision of define statements

Name collisions of define statements become a serious problem, when we 
create a large schema by combining several schemas.  While reading the
RNG version of the OOXML schemas, I find name collisions several
times.  For example:

	dml-baseTypes.rnc:589:1: error: multiple definitions of "ST_Guid"
	without "combine" attribute
	dml-baseTypes.rnc:602:1: error: multiple definitions of
	"CT_Color" without "combine" attribute
	dml-baseTypes.rnc:645:1: error: multiple definitions of
	"CT_Hyperlink" without "combine" attribute

(Note:  I have made sure that a module is never included twice.)

Name collisions happen since all modules share a single symbol 
space for the names of define statements.  Modules included 
(possibly indirectly) share the symbol space of the root schema module.

To be precise, RELAX NG allows more than one symbol space when 
schemas have nested grammars or externlRef (which is a syntax sugar 
for nested grammars).  But they work only for simple cases.  For 
example, suppose that the grammar A contains two nested grammars, namely 
B and C.  Yes, B (and C) can freely reference to define statements 
of A.  However, we can have only one reference from A to B (or C).  In 
other words, we cannot have different references from A to different
define statements of B (or C).  Moreover, B cannot reference to C, and
vice versa.  

W3C XML Schema is different here, since complex types, simple types, 
named model groups, etc. are namespace-qualified.  Thus, collision 
does not happen as long as target namespaces are different.

I do not know the pros and cons of such namespace-qualification.
And we can always avoid the name collision problem by introducing 
a naming convention.  However, we do have to study consider this 
issue seriously.


MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]