[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