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] | [Elist Home]

Subject: Re: combine proposal

I have just read your proposal  (which didn't reach me for some reason) from the WWW.  
It looks promising to me.  Apparently, you have carefully considered observations by 
Kawaguchi-san and me.  As for modularization, RELAX NG is clearly better than TREX 
and RELAX Core.  I am happy.

Let me try to explain reasons behind your proposal.

>Two input <define> elements are combined into a single output <define>
>element as follows.

If we have more than two <define> elements, we combine two of them, and 
recursively go on.   No matter which two we choose, the result is 
guaranteed to be idential.

>The input <define> elements will have been normalized
>so that they contain exactly one child element before they are combined.

This normalization makes this reference model easy.

>It is an error if neither input <define> element has a combine attribute.

This restriction eliminates conflicts between two definitions that
are not intended to be used together.

>It is an error if both input <define> elements have a combine attribute, but
>the values are different.

This allows both <define> elements to the same combine attribute.  In
other words, neither of them are standalone.  In general, a grammar
can have more than one non-standalone definitions as long as all of
them specify the same combine attribute.  Although this may look odd
at a first glance, I also think that this is extremely useful.  For
example, you might want to have definitions of common attributes in
many modules.  You do not know which of these definitions will be
used.  Thus, you always specify combine="group".

By disallowing different values for the combine attribute, we can
eliminate the problem Kawaguchi-san pointed out.

>The output <define> element has a combine attribute with value equal
>to the combine attribute on one or both of the input <define>

Yes, this output <define> has to inherit the combine attribute.  Then, 
we can ensure that all <define> elements for the same named
pattern specify the same value.

>If combine="group", then it is an error if allowsChildren is true for
>both of the patterns in the define elements being combined, where
>allowsChildren is defined as:

Since attributes may occur in any order, we only have to make sure that 
only one of the two patterns allow elements or text.  allowsChildren 
exactly does this.

>I should mention that I believe this proposal can handle XHTML.

I believe so too.  It would be great if Norm could try this proposal
for DocBook.

If our enumeration plays well with the combine attribute, RELAX NG will 
be really great in modularization.  Poweful and safe.



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

Powered by eList eXpress LLC