Re: Review of XML-Data

Hi Gary.

Thanx for the review. My comments and proposals ar einlined, below..

Gary Hallmark wrote on 28/09/2009 22:17:49:
> 
> As I said in the prior review, I don't like the notion that an import 
> profile can be either a tag like
> <http://www.w3.org/2007/rif-import-profile#Generic> or it can be the 
> location of a schema document.
> It is more straightforward to define a fixed set of additional profile 
> IRIs, e.g.
> 
> <http://www.w3.org/2007/rif-import-profile#XML-Data>
> <http://www.w3.org/2007/rif-import-profile#XML-Schema>
> <http://www.w3.org/2007/rif-import-profile#XML-Schema-Valid-Data>
> 
> If the last profile above is specified, then the import syntax includes 
> the location of a data document
> and the location of a schema document (the schema document location may 
> be omitted if it is included in
> the data document).

I see your point. I am neutral about that, and would go either way. Let's 
poll the group at the telecon.

> Definition (Sequence). It is unclear what the relationship is between 
> XDM sequences and rif lists. The
> document has several examples that lead one to believe that some of the 
> XDM sequences will map to rif
> lists. This should be made much more explicit. Exactly how much document 

> ordering will be preserved when
> embedding xml data in rif, and will the ordering always be reflected 
> using rif:List?

The two places where the relationship between sequences and rif:List is 
relevant are in the interpretation of Frames and in the interpretation of 
Atoms.

I modified the definition of Frames to make the relationship explicit 
("...and v is a RIF list that contains the typed value of all the 
information items in the o/slot-sequence, in document order"), see my 
reply to Dave's review.

I propose to do the same for in te section about Atoms.

> Also, if you search for [children], you will see that sometimes this 
> "information item" is described as
> a sequence, and other times as a list. Do you really need a notion that 
> is different from rif:List?

Yes, because information items and atomic values in the data model are not 
RIF constants.

I will check the spec to make sure that sequences are always called 
sequences, and that wherever "list" is used, it is explicitly a RIF list.

> Definition (Atomic value). Is this the same as a rif individual? Does it 

> get mapped to (embedded as) a
> rif individual?
> 
> Definition (Atomic type). Shouldn't this refer to DTB? Or at some point 
> doesn't it get mapped to a DTB data
> type?
>
> Element information items: what rif constructs does this get mapped to? 
> E.g. it says
> <quote>
> [children] An ordered list of child information items, in document 
> order. This list contains only
> element information items and character information items, one for each 
> element and data character
> appearing immediately within the current element.
> </quote>
> Is this is rif:List of children? But then the children need to be 
> rif:Const or rif:List. I think you
> have to unify the domains of XDM and RIF, by mapping the XDM things to 
> RIF things. I'm a bit unclear on
> where the mapping is defined.

The data model is about the XML data, not RIF; it is does not contain RIF 
constructs. The mapping is done in the interpretation of RIF constructs 
wrt data model instances.

I take from your comment that this is not explicit enough. I will look at 
that and make proposals for improvements (but not before the telecon, I 
fear).

> DM-Names:
> 1. XML Name is undefined

You are right. I had XML 1.0 names in mind, hence the wording, but they 
are, really, NCNames. I corrected that.

> 2. if the intent of the NAME 'all(XML Name)' is to result in a list, 
> then it should be renamed to
> 'list(XML Name)'

No problem. I made the change.

> In PRD, can actions change the XDM? can actions change the frames that 
> the XDM maps to? Is the mapping
> bi-directional?

No, data model instances are imported once, when the RIF doc is evaluated. 
Wrt PRD operational semantics, that means that the imported data sources 
are part of the initial state of facts. But we do not have actions to 
update an external data source, so, following Dave's comment wrt the 
previous draft, I removed any notion that an importde data source might be 
modified when the rules in a RIF document are executed.

This is why the interpretations say 'XYZ is true if...' and not 'if and 
only if': a frame whose object, slot name and/or value correspond to items 
in a data model instance may be true even if it is not as a consequence of 
the data model instance saying so. That is, if it is asserted by a PRD 
ruleset, or if it is entailed by a Core or BLD set of rules.

> I am confused by the following:
> <quote>
> Class names
> Constants that occur in a position where the identifier of a class is 
> expected, e.g. in RIF class
> membership and subclass relationship formulas, can be interpreted as 
> identifying subsets of the element
> information items in the instances of the data model that describe the 
> imported data sources
> </quote>
> The seems to imply that the element information items are somehow in the 

> RIF Domain. How did they get
> there, and what is their relationship to other things in the domain? Is 
> there a new Interpretation
> function for them?

The element information items are, indeed, imported in the RIF domain. 
That is what the section "4.2 Variables" is meant to say.

I get it, from your comment, that this is not clear :-)

> I note similar confusion about
> <quote>
> Slot names
> Constants that occur in a position where a slot's name is expected, e.g. 

> in RIF frame formulas, can be
> interpreted as identifying subsets of an element information item's 
> [children] or [attributes]
> properties
> </quote>
> The slot names section also defines a o/slot-sequence whose relationship 

> to rif:List should be
> explained. As is the case for "element information items", it is unclear 

> whether this data is in the RIF Domain or not (and if not, I don't see 
> how the formal semantics can work).

Same: the relation between the data model instances and the interpretation 
of RIF constructs need be clarified, obviously.

> Actually, unless this data also has a RIF syntax, I don't see how 
> production rule actions can affect
> this data. This is important because many production rule systems not 
> only test xml data, but also
> change it.

Again, the spec does not tell you what you do with what your rules have 
asserted/what is entailed by your rules: whether you use that to update an 
XML document, a relation data base, instances of Java objects or just 
throw it away or whatever, depends on your application.

> Variables: this is the wrong place to talk about needing to add the XDM 
> things to the RIF domain. The variables range over the individuals in 
> the domain according to the model theory. I don't know whether you are 
> trying to add XDM things to the domain, in which case you will need to 
> extend the model theory by adding various interpretation functions for 
> the XDM things, or whether you want to map XDM things to RIF notions of 
> Const, list, frame, etc.

The idea was to add constraints on interpretations. Obviously, that part 
need more work. See also the interchange with Dave, on the same subject.
 
> Another example of confusion about the domain:
> <quote>
> Frames: rif:Frame
> A frame o [ slot -> v ], where o identifies an element information item 
> in an imported data model instance, and where v identifies a constant 
> whose DM-Name is defined, is true
> either if the local name in slot DM-Name has the forme all(NAME) and v 
> is the sequence of the typed value of all the information items in the 
> o/slot-sequence, in document order;
> </quote>
> It seems to me that for such a frame to be true, then o, slot, and v 
> must map to the RIF domain, and in particular v would have to be a 
> rif:List or there must be an Interpretation function for "element 
> information item", "o/slot-sequence", etc.
> 
> The editor's note below Example 4.6: Not a good idea. "111" != 111. But 
> we should allow
> <account xsi:type="xs:int">111</account>. Doesn't this come for free 
> (xsi:type affects PSVI)?

I will open a sepcific thread to discuss this point, since the on-going 
discussion with Dave contains it as well.
 
> Editorial:

I will do the correction and report separately.

Thanx again for the detailed discussion.

Cheers,

Christian

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