Re: RIF XML Syntax and translators

Hi Adrian,

> I read them but I don't see why  <formula>, <declare> are necessary. I
> understand the need for  <op> and <object> for example...

The <formula> and <declare> elements are there because the XML syntax
is fully-striped (as explained at the beginning 2.1.1.6.). A
stripe-skipped version of the XSDs is also possible, of course.

> You are right. I was in hurry and therefore wrong. Below is the proposed
> design:
>
>    <xs:element name="CONDITION" type="CONDITION.type" abstract="true"/>
>    <xs:complexType name="CONDITION.type" abstract="true"/>
>    <xs:element name="And" type="And.Type" substitutionGroup="CONDITION"/>

I still don't think that will work because CONDITION and And are of
different types. Have you tested it with, say, XSV?
(http://www.w3.org/2001/03/webdata/xsv)

Another advantage of groups is that they are nicely modular, and can
be used with xs:redefine. Because the XSDs are so far stand-alone
("monolithic"), this hasn't been taken advantage of, but it may be
important in the future.

> I know the document but there is about DTD modularization and it might
> not be the same case for an XMLS.

See appendices A - C of the document for the XML Schemas.

David

On 12/5/07, Adrian Giurca <giurca@tu-cottbus.de> wrote:
> Hi David,
> David Z. Hirtle wrote:
> > Hi Adrian,
> >
> >
> >> 1. How was the proposed XML Schema ( see
> >> http://www.w3.org/TR/rif-bld/#Specification ) derived from the EBNF for
> >> the Presentation Syntax of the RIF-BLD Condition Language
> >> http://www.w3.org/TR/rif-bld/#head-10450be66b637feddd430658ce562ef518ca5b05
> >> ? There is any normative specification of the mapping from EBNF to XML
> >> Schema? or Is the XML Schema normative?
> >> Seems that in the Schema appears a number of elements such as <declare>
> >> ,  <formula>  and is not clear how they are derived from EBNF
> >>
> >
> > You may want to look at the following subsections, not only the EBNF one:
> >
> > 2.1.1.6. XML Syntax
> > 2.1.1.7. Translation Between the Presentation and the XML Syntaxes
> >
> > The latter in particular should make the mapping clear, e.g. showing
> > where <declare> and <formula> fit in.
> >
> I read them but I don't see why  <formula>, <declare> are necessary. I
> understand the need for  <op> and <object> for example...
> However is a pitty  that  the EBNF does not  clarify this in a manner
> similar with OWL abstract syntax. Anyway  we may live also with this
> syntax  if this one is normative. Is it?
> >
> >
> >> 2. The second question is related with the intended meaning of xs:group
> >> which in my opinion is designed to handle collections:
> >> For example we have:
> >> CONDITION   ::= 'And' ' ( ' CONDITION* ' ) ' |
> >>                     'Or' ' ( ' CONDITION* ' ) ' |
> >>                     'Exists' Var+ ' ( ' CONDITION ' ) ' |
> >>                     ATOMIC
> >>
> >> which means that And is a CONDITION i.e. any instance of an And is an
> >> instance of  CONDITION.
> >> If so it might be better to implement as
> >>
> >>  <xs:element name="CONDITION" abstract="true">
> >>   <xs:complexType>
> >>    <xs:choice>
> >>    <xs:element ref="And"/>
> >>    <xs:element ref="Or"/>
> >>    <xs:element ref="Exists"/>
> >>    <xs:element ref="ATOMIC"/>
> >>    </xs:choice>
> >>   </xs:complexType>
> >>  </xs:element>
> >>
> >> and then
> >>
> >>  <xs:element name="And" substitutionGroup="CONDITION">
> >>    <xs:complexType>
> >>     <xs:sequence>
> >>      <xs:element ref="CONDITION" minOccurs="0" maxOccurs="unbounded"/>
> >>
> >>     </xs:sequence>
> >>    </xs:complexType>
> >>  </xs:element>
> >>
> >> etc.
> >>
> >> In this case roles such as <formula> are not needed.
> >>
> >
> > I'm not an expert with substitution groups, but they seem to require
> > that the substituted-in elements (e.g. And) have the same type as the
> > "head" element (in this case, CONDITION), so this probably wouldn't
> > work.
> >
> > http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#SubsGroups
> >
> >
> You are right. I was in hurry and therefore wrong. Below is the proposed
> design:
>
>    <xs:element name="CONDITION" type="CONDITION.type" abstract="true"/>
>    <xs:complexType name="CONDITION.type" abstract="true"/>
>    <xs:element name="And" type="And.Type" substitutionGroup="CONDITION"/>
>    <xs:complexType name="And.Type">
>        <xs:complexContent>
>            <xs:extension base="CONDITION.type">
>                <xs:sequence>
>                    <xs:element ref="CONDITION" minOccurs="0"
> maxOccurs="unbounded"/>
>                </xs:sequence>
>            </xs:extension>
>        </xs:complexContent>
>    </xs:complexType>
>    <xs:element name="Or" type="Or.Type" substitutionGroup="CONDITION"/>
>    <xs:complexType name="Or.Type">
>        <xs:complexContent>
>            <xs:extension base="CONDITION.type">
>                <xs:sequence>
>                    <xs:element ref="CONDITION" minOccurs="0"
> maxOccurs="unbounded"/>
>                </xs:sequence>
>            </xs:extension>
>        </xs:complexContent>
>    </xs:complexType>
>    <xs:element name="ATOMIC" type="ATOMIC.Type" abstract="true"
> substitutionGroup="CONDITION"/>
>    <xs:complexType name="ATOMIC.Type" abstract="true">
>        <xs:complexContent>
>            <xs:extension base="CONDITION.type"/>
>        </xs:complexContent>
>    </xs:complexType>
> ....
> > In any case, I think using groups is the more tried-and-true method
> > for this kind of thing. For example, XHTML uses groups for such
> > "content models" (see http://www.w3.org/TR/xhtml-modularization).
> >
> I know the document but there is about DTD modularization and it might
> not be the same case for an XMLS.  Following XML Schema recommendation
> the meaning of  xs:group is a container for content. I believe that
> CONDITION is the superclass of And  and that's why I propose the above
> design. Moreover, in this case, supplementary roles such as <formula>
> and <declare> are not necessary.
>
> There are also discrepancies in meaning   such as:
> <Frame>
>  <object>inst</object>
>  <slot>key1 filler1</slot>
>   . . .
>  <slot>keyn fillern</slot>
> </Frame>
> Here the content of <object> is the object itself while below the same
> object is content of object/member/lower:
> <Frame>
>  <object>
>    <Member>
>      <lower>inst</lower>
>      <upper>class</upper>
>    </Member>
>  </object>
>  <slot>key1 filler1</slot>
>   . . .
>  <slot>keyn fillern</slot>
> </Frame>
> and later <lower> is used to markup a class (i.e. sub):
>
> <Frame>
>  <object>
>    <Subclass>
>      <lower>sub</lower>
>      <upper>super</upper>
>    </Subclass>
>  </object>
>  <slot>key1 filler1</slot>
>   . . .
>  <slot>keyn fillern</slot>
> </Frame>
>
> I guess this come from the goal to avoid attributes. But is usual that
> the same element markup the same content (in case of <upper> for example).
> I understand that object/subclass/upper is different from
> object/member/upper but I guess is anyway hard...
>
> Anyway, actually I am interested to know just if the syntax is normative
> otherwise I have to wait
>
>
> > David
> >
> Regards,
> Adrian
> >
> > On Dec 4, 2007 10:14 AM, Adrian Giurca <giurca@tu-cottbus.de> wrote:
> >
> >> Dear all,
> >> The REWERSE working group I1 has some experience in implementing
> >> translators
> >> <http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=translators> for
> >> interchange. We consider to start building a number of RIF translators
> >> but we need help to understand a number of  issues:
> >>
> >> 1. How was the proposed XML Schema ( see
> >> http://www.w3.org/TR/rif-bld/#Specification ) derived from the EBNF for
> >> the Presentation Syntax of the RIF-BLD Condition Language
> >> http://www.w3.org/TR/rif-bld/#head-10450be66b637feddd430658ce562ef518ca5b05
> >> ? There is any normative specification of the mapping from EBNF to XML
> >> Schema? or Is the XML Schema normative?
> >> Seems that in the Schema appears a number of elements such as <declare>
> >> ,  <formula>  and is not clear how they are derived from EBNF
> >>
> >> 2. The second question is related with the intended meaning of xs:group
> >> which in my opinion is designed to handle collections:
> >> For example we have:
> >> CONDITION   ::= 'And' ' ( ' CONDITION* ' ) ' |
> >>                     'Or' ' ( ' CONDITION* ' ) ' |
> >>                     'Exists' Var+ ' ( ' CONDITION ' ) ' |
> >>                     ATOMIC
> >>
> >> which means that And is a CONDITION i.e. any instance of an And is an
> >> instance of  CONDITION.
> >> If so it might be better to implement as
> >>
> >>  <xs:element name="CONDITION" abstract="true">
> >>   <xs:complexType>
> >>    <xs:choice>
> >>    <xs:element ref="And"/>
> >>    <xs:element ref="Or"/>
> >>    <xs:element ref="Exists"/>
> >>    <xs:element ref="ATOMIC"/>
> >>    </xs:choice>
> >>   </xs:complexType>
> >>  </xs:element>
> >>
> >> and then
> >>
> >>  <xs:element name="And" substitutionGroup="CONDITION">
> >>    <xs:complexType>
> >>     <xs:sequence>
> >>      <xs:element ref="CONDITION" minOccurs="0" maxOccurs="unbounded"/>
> >>     </xs:sequence>
> >>    </xs:complexType>
> >>  </xs:element>
> >>
> >> etc.
> >>
> >> In this case roles such as <formula> are not needed.
> >>
> >> -Adrian
> >>
> >>
> >
>
>

Received on Friday, 7 December 2007 02:53:08 UTC