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

Re: [ISSUE-37] New proposal on RIF interoperation with XML data and XML Schemas

From: Christian de Sainte Marie <csma@ilog.fr>
Date: Mon, 16 Mar 2009 20:56:44 +0100
Message-ID: <49BEAEFC.8090000@ilog.fr>
To: Dave Reynolds <der@hplb.hpl.hp.com>
CC: RIF WG <public-rif-wg@w3.org>
Hi Dave,

Thanx for the feed-back. Some comments below.

</chair>

Dave Reynolds wrote:
> 
> Well the detailed correspondences they set up between #/frames and XML 
> schema are different and incompatible in detail.


I meant that they are just orthogonal, and that adopting one does not precludes adopting the other as well. Not that I would recommand that, but I did not see anything that would forbid it.

> It seems like there are two different aspects of the proposals and it 
> might be worth separating them out.
> 
> [...]
> 
> Is that a reasonable characterization?


Yes.

> On aspect (1) then the use of import and the style of specification seem 
> reasonable to me.
> 
> On aspect (2) the the detailed mapping of XML Schema elements you 
> propose has several problems.
> 
> Firstly there is more overloading of namespaces in XML Schema than just 
> elements/attributes, the introduction section of [1] gives a list of 
> reasons why qnames are insufficient to designate schema components.


Yes, I am aware that the use of namespaces in my proposal is shaky, to say the least (to tell you the truth, one document you will find, these days, in the bag I carry from home to office and back everyday is the namespace spec)>

But I thought I'd better float my proposal as is, rather than try to fix everything myself :-)

> Secondly, introducing new syntax just for attributes and having to 
> change the semantics to cope with this seems like a huge and completely 
> unnecessary change. It is perfectly possible to define an XML Schema 
> element to IRI mapping which can designate attributes separate from 
> elements so just do that. Gary's mapping is one such example.


Yes, that attribute thing is really an ugly carbuncle on the face of my proposal. The previous (unpublished) version had something more akin to Gary's proposal, only navigating the (possibly virtual) data document instead of the schema. But it occured to me, following a comment by Sandro, that it would not work well with RDF. That's where I tried using bare QNames instead...

> Thirdly, your proposal talks about QNAMEs but RIF currently doesn't have 
> QNAMEs. I'm unclear if you are taking the RDF-style approach of 
> concatenating the components of a QNAME to form an IRI or proposing to 
> add a QNAME datatype. I'm hoping it's the former.


It is, indeed.

> Can you combine your approach to the mapping definition with Gary's 
> actual mapping?


Would using the concatenation of the data document IRI and an absolute XPath location path do? That what I did in the above mentioned previous version. One problem is that it requires an IRI for the data document, whereas one thing I like in the proposal I published is that "canonicalisation" thing, where you do not need a shared XML data document (not even a shared data document).

> My previous comments on Gary's proposal still stand though. Given that 
> designating XML Schema elements by IRIs is a common problem across W3C 
> specs and is already being addressed by [1] is it not possible to just 
> adopt that?


I have to look at it: can you point me more precisely where it is addressed in [1]? I also have to look at the SAWSDL declarations.

Cheers,

Christian
<chair>

> I also still like the idea that where SAWSDL [2] declarations exist in a 
> schema one should use those to define the correspondence to classes and 
> properties (sorry frame slots) and only fall back on XSCD for 
> un-annotated schemas. However, that never seems to have gone down very 
> well before and I don't care about it enough to press the point further.
> 
> Dave
> 
> [1] http://www.w3.org/TR/xmlschema-ref
> [2] http://www.w3.org/TR/sawsdl/
> 
Received on Monday, 16 March 2009 19:57:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:03 GMT