W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2003

Re: Please review RDF Last Call

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Thu, 30 Jan 2003 14:47:34 +0100
To: www-rdf-comments@w3.org, reagle@w3.org, w3c-ietf-xmldsig@w3.org, n-shiraishi@w3.org
Message-Id: <200301301447.34040.jjc@hpl.hp.com>

RDF Core coordination:
   Brian please create an issue "XMLLiteral equality"
   Brian please create an issue "exc-c14n throughout"
   Pat, there is also an editorial fix for you, just below.

> Assuming you mean xmldsig WG (not I18N): <smile/>

egg-on-face - sorry - you did get quite a different message from them, honest 
- but I was modifying a copy (since they are interested in XML Literals in 
RDF too, but lots else besides).

> > ...
> > RDF Semantics
> > http://www.w3.org/TR/rdf-mt/
> > #rdfinterp
> > #dtype_interp

> As an aside, do you intend to actually "require" a particular QName prefix 
> when it says, "which we will refer to as XSD and use the Qname prefix xsd:. 
> "? 

I will leave Pat to pick this point up.

> I'm confused by this because most of the specifications are citing Canonical 
> XML (c14n), not Exclusive Canonicalization (exc-c14n).

The process is intended to be two-phase:

The first phase takes an RDF/XML document and constructs an RDF graph.
In this phase it is not required to actually canonicalize, but it is required 
to retain all the information needed for exc-c14n.

The second phase, which many RDF applications don't actually ever do is from 
the graph to its formal meaning; for these it concerns the meaning of the 
string delivered by the parser. This second stage is determined by the 
mapping defined in RDF Concepts. This second stage uses c14n on the grounds 
that whatever the parser delivered (which is intended as implementation 
dependent) is then preserved.

The semantics doc picks up after the parser has left off, i.e. with the RDF 
graph - at this point we no longer have an XML document to refer to, and so 
we use C14N over the fragment.

Admittedly, it might be clearer to specify the use of exc-c14n throughout - 
this would work except for nasty cases like XSLT, that invisibly use the 
namespace prefices.

> I presume that the reason you even care how the xml-literal is represented 
> is that you will want to compare RDF instances (which might contain 
> xml-literals) to see if they are identical at some point? If that's the 
> case, then won't you want the character/octet representation of XML within 
> a RDF representation to be equivalent as well? For example, if you are 
> comparing two RDF blobs for identity, you wouldn't want the two 
> xml-literals to be different because one implementation cared about 
> comments and the other didn't...?

This is a good point. Brian please assign an issue number.

Initially the goal of working on XML Literals was simply to get visibly used 
namespaces to work at all. This goal is achieved; but for certain 
applications we have not achieved interoperability.

> First, again, what purpose is a canonicalization even serving if you are 
> likely to get implementation variances? 

It *is* an improvement on where we used to be!
So, there is quite a lot of clarity as to what the contract is, but we have 
tried to remember the more casual implementor.
If an implementor decides they only want to partially support these literals, 
they could choose say to always bind  the default namespace to xhtml and not 
support any other binding. The string for the literal is then essentially a 
copy straight out of the input document. 
Other users need the precision that you talk about - which as you point out we 
haven't delivered.

Hmmm ... I will try and defend the decisions we have made a bit more.

The fundamental problem we are addressing is *how* to repesent XML content 
within an RDF graph. This XML content originates from an RDF/XML document, 
but, that original context gets lost. Thus we face a number of problems 
familiar in exc-c14n, what to do about entities?, what to do about visibly 
used namespaces? what to do with namespaces that are present but not visibly 
used? These issues are the pressing ones that are addressed by the Last Call 
docs. A further issue of making sure that two different implementations get 
exactly the same answer was not one that we felt it necessary to address.
I will ask the WG to reconsider whether this was correct as part of the LC 

> > This behaviour is conformant but not required.
To the RDF Last Call documents.

Thanks for your comments, Brian should assign an issue number concerning the 
implementation variability, Pat should follow up on the misleading wording 
about the xsd namespace in semantics.

Received on Thursday, 30 January 2003 13:46:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:01 UTC