Re: spec of multi-sorted Core should include the ASN productions

I completely agree with this approach. It is valid  for  the Core too.
Some time ago I pointed out  a number of issues 
<http://lists.w3.org/Archives/Public/public-rif-wg/2007Feb/att-0063/00-part>:

    * there is no clearly defined mapping from the abstract syntax to
      the XML Schema.
    * we don't know what are the extensibility principles  for the RIF
      Core (RIF PRR is an *extension *).

Recall the old proposal (it is hard to find by searching on the mailing 
list since is stored as attachment ) was:

    * An  *XML Syntax* section (subsection of *SYNTAX*) can be created.
      Two mappings from BNF syntax to the XML syntax can be then placed
      here (BNF2DTD and BNF2XMLS). These mappings will define how the
      DTD is created from the BNF and how XML Schema can be created too.
      Examples in XML syntax can come here too. /Another solution is to
      create XML Schema directly from MOF  which is immediate possible/.
      (MOF2XMLS)
    * A *Datatypes *section is desirable. This section will explain
      which datatypes are allowed and describe them.
    * A specific *Validation *section which includes all kind of
      validation issues i.e. DTD validation, XML Schema validation, MOF
      validation.

which can be done for ASN06 if the language has the same representation 
power as MOF/UML. If not then this can be done  from EBNF to XML Schema.

    * After that any extension conforming with extensibility principles
      can be done. I am wondering about extensibility principles since I
      guess these principles apply to the XML Schema of the extensions
      too. Then  the general extensibility principles must be somehow
      compatible with the XML Schema capabilities.
    * Another crucial issue for me is if the extensions will *include
      *the actual semantics.

Finally, now XPath 2.0 is recommendation and provides a *large *set of 
functions. In R2ML 
<http://oxygen.informatik.tu-cottbus.de/rewerse-i1/?q=R2ML> we use then  
and until now we did not find any inconvenience. A number of builtin 
datatype predicates is desirable too. We use now the SWRL builtins.

-Adrian



Gary Hallmark wrote:
> I was trying to build a little RIF translator for Oracle Business 
> Rules (OBR).  OBR is "strongly typed" like Java and so I want to use 
> the multi-sorted Core.  The "design" for my translator is
>
> 1. obtain an XML Schema document for multi-sorted RIF Core
> 2. use JAXB/2.0 to generate Java classes and xml 
> marshaller/unmarshaller from (1)
> 3. write a RIF "import" utility Java program that walks a RIF document 
> expressed using (2) and creates production rules in OBR
> 4. write a RIF "export" utility Java program that creates a RIF 
> document from an OBR ruleset (or explains why translation isn't possible)
> 5. add some builtins from xquery/xpath like op:numeric-add which are 
> sorted and without which it's kind of hard to write any useful rules 
> at all
>
> It is reasonably straightforward to generate (1) from the ASN in the 
> Core spec, although the Schema isn't uniquely determinable from the 
> ASN (possibility of stripe skipping, etc), which is a big problem for 
> interoperability.
>
> Unfortunately, the ASN in the Core spec does not include support for 
> multiple sorts.  The "sorting" is kind of "added on" toward the end of 
> the spec, and the ASN is never completely revealed.  I think it's 
> pretty easy to guess about the primitive sorts from the examples, but 
> the arrow sorts and boolean sorts really need to have ASN. 
>
> -- 
>
>
> Oracle <http://www.oracle.com>
> Gary Hallmark | Architect | +1.503.525.8043
> Oracle Server Technologies
> 1211 SW 5th Avenue, Suite 800
> Portland, OR 97204


-- 
Dr. Adrian Giurca
http://www.informatik.tu-cottbus.de/~agiurca/

Received on Thursday, 10 May 2007 07:48:06 UTC