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: combine proposal


Here's a proposal to deal with the combine issue.  My view is that
order-independence is highly desirable, but it's also essential to be able
to redefine things. My proposal:

1. Remove combine="replace".

2. Restrict combine="group" to cases where the order of the patterns being
combined is irrelevant (eg two <attribute> patterns).

3.  Allow a grammar-level <include> to contain one or more <define>
elements.  These <define> elements replace any definitions from that
include.

4.  We have an open issue on giving different names to the grammar-level
include and pattern-level include elements, which we might want to consider
at this time.  I would suggest leaving the pattern-level include as
"include", since it is close to a pure syntactic include, and renaming the
grammar-level include to "integrate".  Other suggestions for renaming are
welcome; I think this proposal really needs the grammar-level include and
pattern-level include to have different names.  Another possibility would be
"incorporate".

More details on 2.

Two input <define> elements are combined into a single output <define>
element as follows.  The input <define> elements will have been normalized
so that they contain exactly one child element before they are combined. It
is an error if neither input <define> element has  a combine attribute. It
is an error if both input <define> elements have a combine attribute, but
the values are different. The output <define> element has a combine
attribute with value equal to the combine attribute on one or both of the
input <define> elements.  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:

function boolean allowsChildren(pattern p) {
  switch (p) {
  case <oneOrMore> p1 </oneOrMore>:
     return allowsChildren(p1);
  case <interleave> p1 p2 </interleave>:
  case <group> p1 p2 </group>:
  case <choice> p1 p2 </choice>:
     return allowsChildren(p1) || allowsChildren(p2);
  case <anyString/>:
  case <element/>:
  case <data/>:
  case <string/>:
    return true;
  case <empty/>:
  case <notAllowed/>:
  case <attribute/>:
    return false:
  case <ref name=x/>:
    return allowsChildren(deref(x));
  }
}

(this assumes <notAllowed/> has been normalized out so that it occurs only
as a child of <define/>).

More details on 3.

<grammar>
<integrate href="X">
  <define name="Y">...</define>
</integrate>
...
</grammar>

is the same as

<grammar>
<integrate href="X"/>
<define name="Y">...</define>
...
</grammar>

except that any definitions of Y directly or indirectly inside X are ignored
(other than definitions inside nested grammars).  Note that a <define>
element inside the <integrate/> may have a combine attribute.   The same
rule applies in this case as well:

<integrate href="X">
  <define name="Y" combine="Z">...</define>
</integrate>
...

is the same as

<integrate href="X"/>
<define name="Y" combine="Z">...</define>
...

except that any definitions of Y directly or indirectly inside X are
ignored.

James






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


Powered by eList eXpress LLC