Fw: [relax-ng-comment] conformance test

[James Clark <jjc@jclark.com>]

I think this comment identifies a bug in the spec. Section 4.20 (the section
on notAllowed) should say that any definitions that are made unreachable by
the simplification of notAllowed are removed.

----- Original Message -----
From: "Gary Stephenson" <garys@ihug.com.au>
To: <relax-ng-comment@lists.oasis-open.org>
Sent: Friday, November 09, 2001 6:29 AM
Subject: [relax-ng-comment] conformance test


> Hi all,
>
> 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>
>
>
>