W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2008

BLD mini-review

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Mon, 18 Feb 2008 12:34:34 +0000
Message-ID: <47B97B5A.5080103@hplb.hpl.hp.com>
To: RIF WG <public-rif-wg@w3.org>

I generated a wiki-tr version on Friday 15th so I hope I was working on 
the up to date version.

** Overall

Having both the FLD-specialization and the standalone versions of the 
specification makes for a slightly confusing document but I can see the 
argument for why having BLD standalone is useful.

Whilst the semantics is clear and formally specified the XML syntax is 
too loosely specified. If that's a known and understood limitation of 
the current draft then you can ignore nearly all of the specific 
comments below.

** 2.0.1

For the list of supported Symbol Spaces it might be worth reiterating 
the "and subspaces" comment from RIF-FLD (if that is retained) so that 
people comparing earlier documents realize that xsd:integer and xsd:long 
are still included.

Suggest last paragraph at end of 2.0.1 ("In order to make this document 
self-contained ...") plus 2.0.2 through to 2.0.5 be put in a separate 
section. The transition from describing the FLD specialization, to 
repeating that material with the specialization and then on to adding 
new material (2.0.6) is confusing. Indeed that section could be made 
into an appendix to simplify life for people who have read FLD while 
still leaving the document standalone.

** Example 1 (and later presentation syntax examples)

The examples use CURIE style notation for instances of rif:iri whereas 
the definition of that symbol space is IRIs not CURIEs. Should add a 
remark after the EBNF to explain that such expansion is to be assumed if 
that's what you mean (which I expect it is for the presentation syntax).

** Example 2

s/10/10^^xsd:integer/ (twice)

** XML for RIF-BLD Condition Language + Appendix 5.1

(a) Should specify which version of XML is to be used.

(b) In the table should spell out that each of those names is the XML 
element name corresponding to the intended "classes, roles" and are 
within the RIF namespace.

The reference to the XSD definition is not sufficient to specify several 
aspects of the syntax processing:

(c) 'type' attribute. I assume from FLD and the examples this is 
intended to be a CURIE rather than a IRI. In that case it this should be 
spelt out and the processing model for that needs to be defined 
precisely. If not (the easy option) then the examples need fixing.

(d) Doesn't specify use of xml:lang for the language tag on Const 
elements of type rif:text which I thought had been agreed.

(e) Given that the elements are qualified I think the attributes should 
also be qualified. At least 'type' should become 'rif:type'.

(f) Doesn't specify any CURIE processing for the element content for 
Const elements of type rif:iri. I think there shouldn't be any and the 
examples need fixing. If the intention is that there is some then this 
will need a precise definition.

(g) Example 3 should give a complete XML document with headers including 
prefix definitions, not just a document fragment as at present.

(h) Depending on the resolution of (c) and (e) above then in the 
examples replace uses of:
     <Const type= ...
     <Const rif:type= ...

and instances like:
     <Const type="rif:iri">bks:LeRif></Const>
     <Const rif:type="rif:iri">http://example.com/books#LeRif></Const>

** Example 5

About 2/3 of the way down replace:
    <op><Const type="xsd:long">reject</Const></op>
    <op><Const type="rif:local">reject</Const></op>

(and then qualify type to rif:type if (e) is agreed).

** 2.0.9

Why allow equality formulae in rule conditions in RIF-CORE?

Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Monday, 18 February 2008 12:35:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:49 UTC