Re: FW: Jing & Trang errors when processing RNC gr ammar

Hutchison, Ben wrote:
> Well, Im impressed by the rapid and authorative responses I have 
> received to my questions; thanks due to Bob and Makoto.
> 
> Further queries inline below. Apologies if they seem elementary, but Ive 
> no formal training or prior experience developing grammars/schemas.
> 
>  > -----Original Message-----
>  > From: Bob Foster [mailto:[email protected]]
> ...
>  > can't be sure it's what the author meant. Why is the platform
>  > attribute
>  > optional and the name attribute not? Both are optional in the revised
>  > version. It is possible the following would be a more faithful fix:
> 
> Indeed. I do require a strictly mandatory name attribute, but an 
> optional platform attribute.
> ...
>  > > error message I cannot understand: E "oneOrMore" contains "group"
>  > > contains "attribute"
>  >
>  > ConfigGroupEntry* where ConfigGroupEntry has as an alternative
>  > ConfigValue, a group that contains a group,
>  > NamedElementAttributes, that
>  > contains two attributes.
> 
> Ok...why is this illegal?

I'm not qualified to say _why_ it's illegal. I'm sure MURATA Makato 
knows. I just wanted to help you find out for yourself what the issue 
is. If you check the RELAX NG specification, you'll find, in section 
7.1.2, a prohibition of the path:

oneOrMore//group//attribute

and others. RELAX NG doesn't allow any arbitrary pattern one might 
specify; the design is a balance between expressive power and the 
ability to write a practical, robust validator. The good news is that 
RELAX NG has far fewer restrictions than other pattern-based schema 
languages, and because of the clarity of its spec it is much easier to 
understand what those restrictions are.

>  > The "oneOrMore" reference is because * (zeroOrMore) is
>  > defined in RELAX
>  > NG as +? (optional oneOrMore).
> 
> Ah! That was confusing me. I couldn't see any oneOrMore pattern in my 
> grammar.
>  >
>  > NamedElementAttributes is obviously redundant as it is used,
>  > so a simple
>  > fix would be to take it out of ConfigValue.
> 
> Why is it obviously redundant? I want NamedElementAttributes present on 
> both ConfigGroups and ConfigValues. Thats why I had specified it in both 
> clauses of my original (problematic) grammar.

I meant it was redundant as used. More than one path in the definition 
of element ConfigGroup led to NamedElementAttributes, and that was the 
only place ConfigGroupEntry/ConfigValue was used.

>  > Trang can't convert everything, esp. an invalid schema, and
>  > even if it
>  > did the conversion could not be faithful where there is a
>  > choice between
>  > an attribute and an element. XML Schema can't describe this.
> 
> By "choice between an attribute and an element", do you mean a case of 
> either sub-element OR attributes? I didn't think I had such a case in my 
> grammar, and I certainly dont mean to.

You did have such a case, though. ConfigGroupEntry had as alternatives a 
ConfigGroup (an element) and ConfigValue (a group that contained 
attributes). If in an instance document you specified one of the 
attributes, you could not also have a nested ConfigGroup element.

Bob

> Thanks
> Ben