Re: Review of XML-DATA

Dave,


Dave Reynolds wrote on 26/09/2009 14:11:29:
> 
> Overall this version is much better than the previous and, with two 
> exceptions and some editorial tweaks, is OK to publish as a working 
draft.

Thanx for the review. Comments and discussion/proposed resolution on your 
issues are inlined below.

> 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.

In principle, I agree. The problem is that rif:iri must be absolute IRIs, 
as you pointed out in your initial review.

Thus, rif:iri constant cannot be used for the case where an 
element/attribute does not ave a namespace.

You suggested to use the base URI, in that case, but I have an issue with 
that (besides the problem of mixing namespace URIs and base URIs in the 
treatment): the base URI is specific to a document. What if my RIF 
document imports several data sources, and I want to refer to an 
information item across all these documents, and that information item's 
name is defined without a namespace? Even the heavy solution of 
introducing disjunctions to cover all the imported documents does not 
work, as soon as yo uthrow the dynamically imported data sources in the 
picture.

So, I agree that considering only rif:iri constants would be better, but 
that would require a change in the definition of rif:iri, which would 
raise a whole new batch of difficulties, making the solution potentially 
worse than the problem it solves...

The definition of DM-Names, in the current draft, essentially allows 
rif:iri constants and xs:NCName constants to have a DM-Name: would it be 
better if the definition was restrcited to say exactly that?

> 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. 

That section needs more work, indeed. But I thought that it was exactly 
for the reverse reasons : it seems to me that the requirement about the 
domain of variables makes better sense in a model-theoretic specification 
of the semantics than in PRD's operational one.

Maybe it is only the wording? The point is that, in any interpretation, 
Dind (that is, the domain that is used to interpret the variables) must 
contain "the data model instances etc".

> 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.

I do not want to make the embedding normative, because I believe that it 
would be a burden on adoption if we required that conformant 
implementation be actually able to produce the RIF facts from a data 
source.

Re providing a model-theoretic semantics for the RIF/XMLcombination, what 
do you ean exactly (I mean, in addition to the definitions provided in 
sections 4.3-4.6? Something like: a RIF+XML interpretation satisfies the 
RIF+XML combination if it is a RIF model and it satisfies the additional 
constaints set in section 4.3 to 4.6?

> 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 agre with that solution: the semantics of combination needs also be 
defined more precisely wrt the operational semantics of PRD, as it 
essentially requires embedding, in the current form.

> 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.

The point is that, when the type of the (atomic) content of an information 
item is unknown, its literal representation is returned as an xs:string. 
So, the proposal is not to equate a string with an integer, but to accept 
the equality of an integer and one of its literal representation, provided 
the later is untyped.

So, the solution might be to leave the [typed representation] property 
empty when there is no typing information, and introduce a [literal 
representation] property for that purpose?
 
> ** Editorial

I will propose correctiosn in a further email (tomorrow).

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