W3C home > Mailing lists > Public > public-rif-wg@w3.org > September 2009

[XMLdata] Proposed editorial notes ofr FPWD (Was: Re: Review of XML-DATA)

From: Christian De Sainte Marie <csma@fr.ibm.com>
Date: Wed, 30 Sep 2009 17:14:16 +0200
To: Dave Reynolds <der@hplb.hpl.hp.com>
Cc: RIF WG <public-rif-wg@w3.org>
Message-ID: <OFB9B9619D.E8AE3781-ONC1257641.004E9A03-C1257641.0053B518@fr.ibm.com>
Dave, Gary,

Here are the editorial notes that I propose, for each of your substantive 
remarks. I have included the editorial notes already in the draft, so 
that, if you agree with tem, we can publish already.

- DM-Names

Dave Reynolds wrote on 26/09/2009 14:11:29:
> The first exception is Section 4.1.1 on DM-Name. I don't think we should 

> define a DM-Name for all rif constants via casting to xs-string. Only 
> rif:iri constants should have a DM-Name, using the same algorithm you 
> give here.  I see no advantage in being able to treat, e.g., a string as 

> corresponding to an XML information item.

I have modified the definition to all only rif:iri and xs:NCNAme constants 
to have DM-Names, and I have added the following editoria lnote:

Editor's Note: The definition of DM-Name is still under discussion. It 
would be preferable if only rif:iri constants had DM-Names, but that would 
exclude element and attribute names that are not in a namespace (since a 
rif:iri must be an absolute IRI). An related issue is whether it would be 
useful to be able to relate an element/attribute name with an imported 
document, and how. 

> The other non-editorial issue is section 4.2. The notion of the "domain 
> of all variables" is not something that is meaningful in BLD, only (I 
> assume) in PRD.  I think you either need to make the embedding (when it 
> is done) normative or provide a model-theoretic semantics for the 
> RIF/XML combination in the same way that Jos did for SWC. However, I'd 
> be happy for the document to be published in this state with just an 
> Editor's Note explaining that that section will be reworked.

I have changed "domain of all variables" to "domain of interpretation of 
the variables", which is, I think slightly mo reprecise.

Moreover, I have changed the title of hte whole section from "Rif as an 
implementation of the data model" to "RIF combination with XML documents", 
an I have added the following editorial note, in the introduction of the 
section (just before section 4.1):

Editor's Note: This draft suggests that XML data is imported as RIF facts, 
but it does not specify precisely how RIF data types, constants, lists and 
individuals relate to type names and atomic types, typed values, sequences 
and information items in the data model, respectively; nor does it specify 
precisely how a RIF variable can be bound to, or interpreted with respect 
to an information item, beyond requiring that the information items in an 
imported data model instance be part of the domain of interpretation of 
the variable (Section 4.2. Variables). This whole section will be 
reworked, in a future draft, to provide a proper semantics for the 
combination of RIF documents with XML data (a model-theoretic semantics 
for combinations involving RIF-Core and RIF-BLD documents, and an 
operational semantics for combinations involving RIF-Core and RIF-PRD 

This note is meant to cover Dave's comment re the "domain of variable", as 
well as Gary's comments re sequences, atomic values, atomic type, element 
information items, class names, slot names, variables and frames!

Does it work for you?

> For the record, I don't agree with the Editor's note after example 4.6, 
> equating a string to an integer is something I think we should avoid. 
> However, that need not hold up publication as a working draft since it 
> is already clearly marked as to be discussed.

I rephrased the editorial to make it more explicit that this was under 

Editor's Note: The typed-value, in the schema-less case, is the 
string-value, that is, a string. So, the xs:integer 111 is not equal to 
the typed-value of the Account node. It is still under discussion whether 
to keep the equality nonetheless, in the schema-less case, because the 
type of the RIF constant gives a hint about the intended data model to the 

> ** Editorial
> ** Section 1
> [...]
> Delete para7 ("However, an instance of the data model can be ....") 
> since the rest of the document has dropped the direct mapping from 
> relational tables.

I have replaced the paragraph with te following editorial note:

Editor's Note: It is intended that, in a future draft, an instance of the 
data model can also be constructed from non-XML sources such as relational 
tables in a database or object instances. In this case, a RIF document 
will be interpreted with respect to the serialization of the source 
according to an XML schema that MUST be imported in the RIF document. 

Tell me if you are happy with these changes, and if we can publish; or, if 
you are not, what you would be your preferences and/or requirements.



ILOG, an IBM Company
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel. +33 1 49 08 35 00
Fax +33 1 49 08 35 10

Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 02430
Received on Wednesday, 30 September 2009 15:15:00 UTC

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