Re: [relax-ng-comment] conformance testing

[Gary Stephenson <garys@ihug.com.au>]

Hi Jiri,

Yes, I do believe you are correct - although the content of the start element
would actually be interpreted as a sequence (group) - not a choice.

I had failed to notice that in the <start> production for the full syntax
(prior to simplification), only a single pattern is allowed.

Thanks,

gary

----- Original Message -----
From: "Jiri Jirat" <Jiri.Jirat@systinet.com>
To: "Gary Stephenson" <garys@ihug.com.au>
Sent: Tuesday, November 13, 2001 8:13 PM
Subject: Re: [relax-ng-comment] conformance testing


> Hello Gary,
>   I am jsut trying to learn RelaxNG, so I am no expert and
> my response is not normative :-)
>
> The example 81 is not valid according to RelaxNG
> schema (Appendix A), because there is a *choice* among
> patterns - it's not allowed to have both "element" and "empty" element
> as a children of "start" element.
>
>
> Regards
> Jirka
>
>
>
> Gary Stephenson wrote:
>
> > Hello,
> >
> > In test no 81 of James' test suite, the following is asserted to be
invalid
> >
> > <grammar xmlns="http://relaxng.org/ns/structure/0.9">
> >   <start>
> >     <element name="foo">
> >       <empty/>
> >     </element>
> >     <empty/>
> >   </start>
> > </grammar>
> >
> > What is wrong with this?  After simplifying up to step 4.19 (before
processing
> > <empty/>s I get:
> >
> > ( T_Root :
> >     ( T_Grammar :
> >         ( DEFINE - start :
> >             ( T_Group :
> >                 ( REF : __sub__2 )
> >                 ( T_Empty )
> >             )
> >         )
> >         ( DEFINE - __sub__2 :
> >             ( ELEMENT (
> >                 ( EXPANDED-NAME : {,foo} )
> >                 ( T_Empty )
> >             )
> >         )
> >     )
> > )
> >
> > After applying step 4.20 I get:
> >
> > ( T_Root :
> >     ( T_Grammar :
> >         ( DEFINE - start :
> >             ( REF : __sub__2 )
> >         )
> >         ( DEFINE - __sub__2 :
> >             ( ELEMENT (
> >                 ( EXPANDED-NAME : {,foo} )
> >                 ( T_Empty )
> >             )
> >         )
> >     )
> > )
> >
> > which seems OK to me.  I can't understand where the invalidity is supposed
to
> > come from.
> >
> > Last week I posted the following message, with no response (as yet).  If
this
> > is because this is not the correct list for posting such messages, please
let
> > me know, and I will cease and desist.  I am not a member of OASIS, and
cannot
> > currently afford to join, so if this means that I am unable to get further
> > assistance in progressing my implementation further then so be it.
> >
> > In test no 292 from James Clark's test suite we have :
> >
> > <?xml version="1.0" encoding="utf-8"?>
> > <choice xmlns="http://relaxng.org/ns/structure/0.9">
> >   <element name="foo">
> >     <empty/>
> >   </element>
> >   <group>
> >     <notAllowed/>
> >     <element name="bar">
> >       <group>
> >         <data type="token"/>
> >         <data type="token"/>
> >       </group>
> >     </element>
> >   </group>
> > </choice>
> >
> > After running this through the simplification process - but before
executing
> > step 4.19 (process notAllowed's) I get :
> >
> > ( T_Root :
> >     ( T_Grammar :
> >         ( DEFINE - start :
> >             ( T_Choice :
> >                 ( REF : __sub__2 )
> >                 ( T_Group :
> >                     ( T_NotAllowed )
> >                     ( REF : __sub__3 )
> >                 )
> >             )
> >         )
> >         ( DEFINE - __sub__2 :
> >             ( ELEMENT
> >
> >                 ( EXPANDED-NAME : {,foo} )
> >                 ( T_Empty )
> >             )
> >         )
> >         ( DEFINE - __sub__3 :
> >             ( ELEMENT
> >
> >                 ( EXPANDED-NAME : {,bar} )
> >                 ( T_Group :
> >                     ( DATA : token )
> >                     ( DATA : token )
> >                 )
> >             )
> >         )
> >     )
> > )
> >
> > After executing step 4.19 - i.e. removing the notAllowed's I end up with:
> >
> > ( T_Root :
> >     ( T_Grammar :
> >         ( DEFINE - start :
> >             ( REF : __sub__2 )
> >         )
> >         ( DEFINE - __sub__2 :
> >             ( ELEMENT
> >
> >                 ( EXPANDED-NAME : {,foo} )
> >                 ( T_Empty )
> >             )
> >         )
> >         ( DEFINE - __sub__3 :
> >             ( ELEMENT
> >
> >                 ( EXPANDED-NAME : {,bar} )
> >                 ( T_Group :
> >                     ( DATA : token )
> >                     ( DATA : token )
> >                 )
> >             )
> >         )
> >     )
> > )
> >
> > Note that the __sub__3 define has now been "orphaned" - there is no longer
any
> > reference to it. When I then run content-type check (section 7.2) I get a
> > content-type error for that define - 'coz groupable( data(), data() ) -->
> > false.
> >
> > So, it would appear that after running simplification steps 4.19 and 4.20,
I
> > need to again check for and remove any define's orphaned in the process -
yes?
> >
> > Also,  is my processor correct in rejecting the __sub__3 element pattern
as
> > not having a defined content-type?
> >
> > Many tias,
> >
> > gary
> >
> >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
>
>
> --
>   <name firstName="Jirka" surname="Jirat"/>
>   <mail>     jiratj@systinet.com  </mail>
>   <support>  http://www.zvon.org </support>
>   <zvonMailingList> http://www.zvon.org/index.php?nav_id=4
> </zvonMailingList>
>
>