Re: RIF XML Syntax and translators

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 Wednesday, 5 December 2007 23:35:58 UTC