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

Review of XML-Data

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Mon, 28 Sep 2009 13:17:49 -0700
Message-ID: <4AC119ED.5050203@oracle.com>
To: RIF WG <public-rif-wg@w3.org>, Christian de Sainte Marie <csma@ilog.fr>
Hi Christian,

Overall, this version is much improved compared to the prior version. I 
think we are close to a first
working draft. Here are a few substantive issues and a few editorial issues.

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

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?

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?

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.

DM-Names:
1. XML Name is undefined
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)'

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

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?

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

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.

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.

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)?

Editorial:

The 2 phrases "XML document" and "XML data source" are used 
interchangeably. For concreteness and
without loss of generality, "XML document" should be used consistently 
throughout.

Definition (Instance of the data model). An instance*s* of the data 
model (remove the *s*)

I don't understand the "resp." clause in the following:
<quote>
child::[prefix:]NAME, resp. child::schema-element([prefix:]NAME), if 
the, optional, namespace URI in C' s DM-Name is URI and if the local 
name is NAME.
</quote>

spelling: forme (should be form)
Received on Monday, 28 September 2009 20:20:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 28 September 2009 20:20:04 GMT