- 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 documents). 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 discussion: 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 consumer. > ** 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. Cheers, Christian 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 Courbevoie 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