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: Request of Clarification: include and combine



> Followings are my current understanding. Is there any false statement?
>
>
> * The combine attribute is allowed for <define>s under a <grammar>, but
>   not allowed for <define>s under a grammar-level <include>.

The proposal was that they *were* allowed in a <define> under a
grammar-level <include> as well.

<grammar>
<include ...>
  <define name="foo" combine="interleave">
   ...
  </define>
</include>
</grammar>

is that same as

<grammar>
<include ...>
<define name="foo" combine="interleave">
...
</define>
</grammar>

except that any definitions of foo from the include are omitted. This is
useful because this grammar may in turn be included into other grammars.
There's no need to make a special case of define in include.

> * Nothing but "choice" and "interleave" are allowed as values of the
>   combine attribute.

Right.

> * It is an error to have <define name="foo"> under an <include>, if "foo"
>   is not defined in the included file. (?)
>
>   In other words, the following grammar is an error.
>
>   A.rng
>   <grammar>
>     <define name="foo"> ... </define>
>     <include href="B.rng">
>       <define name="foo"> ... </define>
>     </include>
>   </grammar>
>
>   B.rng
>   <grammar/>
>
>   I guess this is hard to implement ...

I don't think the proposal addressed this issue.

Your example seems to be mixing two different issues.  Consider just:

A.rng
  <grammar>
    <include href="B.rng">
      <define name="foo"> ... </define>
    </include>
  </grammar>

  B.rng
  <grammar/>

If the user has done this, then they have probably made a mistake.  On the
other hand the semantics are clear.  We can either make this an error or
suggest that implementations give a warning.  Please open an issue on this
one.

>
> * It is an error to declare the same pattern twice in the same file,
>   regardless of the use of the combine attribute. (?)
>
>   In other words, the following grammar is an error.
>
>   <grammar>
>     <define name="foo"> ... </define>
>     <define name="foo" combine="choice"> ... </define>
>   </grammar>

That's my understanding of the current situation.

>   Why is this an error?

The reason why I made this an error in TREX is that I think this makes
schemas harder to read.  At the moment, if you see a definition of "foo" in
the grammar, you know that that definition is the complete definition of
"foo" from that file; you don't have to keep looking through the file. If
you allow definitions in the same file, then you always have to look through
the whole file in order to be sure what the complete definition is. If a
reader comes across

<define name="foo">
 ...
</define>

(no combine attribute), they naturally assume it is the only definition in
the file.

I found myself confused by this when reading RELAX grammars. I would find a
reference to a label foo, then look for an elementRule foo; when I found it,
I would assume it's the only definition.  My assumption would be incorrect,
and I would therefore misunderstand the schema (though eventually of course
I would notice the other definitions and understand correctly).

The other side of the argument is that this is an extra complication, and
makes things slightly harder to explain.

Please open an issue on this one too.

> * It is an error to declare the same pattern with different combine
>   methods.
>
>   In other words, the following grammar has an error.
>
>   A.rng:
>   <grammar>
>     <define name="foo"> ... </define>
>   <?grammar>
>
>   B.rng
>   <grammar>
>     <include href="A.rng"/>
>     <define name="foo" combine="choice"> ... </define>
>   </grammar>
>
>   C.rng
>   <grammar>
>     <include href="B.rng"/>
>     <define name="foo" combine="interleave"> ... </define>
>   </grammar>
>
>
> * However, it is *NOT* an error to use a different combine method, once
>   it is redefined.
>
>   In other words, the following grammar is OK:
>
>   A.rng:
>   <grammar>
>     <define name="foo"> ... </define>
>   <?grammar>
>
>   B.rng
>   <grammar>
>     <include href="A.rng"/>
>     <define name="foo" combine="choice"> ... </define>
>   </grammar>
>
>   C.rng
>   <grammar>
>     <include href="B.rng">
>       <define name="foo"> ... </define>
>     </include>
>   </grammar>
>
>   D.rng
>   <grammar>
>     <include href="C.rng"/>
>     <define name="foo" combine="interleave"> ... </define>
>   </grammar>

Right: the definitions of foo in A.rng and B.rng become irrelevant, since
the definition in C.rng has replaced them.

> * It is an error to have two <define>s, both without @combine, and share
>   the same name.
>
>   In other words, the following is an error.
>
>   A.rng:
>   <grammar>
>     <define name="foo"> ... </define>
>   <?grammar>
>
>   B.rng
>   <grammar>
>     <include href="A.rng"/>
>     <define name="foo"> ... </define>
>   </grammar>

Right.

> * It is *NOT* an error for all <define>s with the same name to have
>   @combine.
>
>   A.rng:
>   <grammar>
>     <define name="foo" combine="choice"> ... </define>
>   <?grammar>
>
>   B.rng
>   <grammar>
>     <include href="A.rng"/>
>     <define name="foo" combine="choice"> ... </define>
>   </grammar>

Right.

James





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


Powered by eList eXpress LLC