OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng-comment message

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


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>




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


Powered by eList eXpress LLC