W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2003

RE: reagle-01, reagle-02 issues

From: pat hayes <phayes@ai.uwf.edu>
Date: Fri, 28 Feb 2003 09:00:45 -0600
Message-Id: <p05111b0fba8528ad222e@[10.0.100.86]>
To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Cc: w3c-rdfcore-wg@w3.org

>  >
>>  The other question is: which X?  I assume the choices are Exclusive
>>  or Canonical, with/without comments.  Did we get a recommendation or
>>  suggestion from the commenters?
>
>Reagle says:
>(I recommend you use exc-c14n).
>
>see
>http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0128.html
>
>that leaves the comments issue open, but (realistically) excludes the
>preservation of namespaces that are not used.
>
>>
>>
>>  > =====
>>  > 3 is now my preference - I realise it needs expansion, but
>>  before I do that
>>  > I wish to list pros and cons, and get feedback from WG.
>>  > =====
>>  >
>>  > Consider three use cases:
>>  > A) cheap and cheerful RDF impl using embedded XHTML
>>  > B) OWL or other semantically advanced use where it is desired that
>>  > representation in domain of discourse is not implementation dependent.
>>  > C) Embedding XSLT document inside and rdf:XMLLiteral (hence requiring
>>  > support for preservation of not visibly used namespaces)
>>  >
>>  >
>>  > 1:
>>  > A - works
>>  > B - doesn't really work, because of comments and not visibly
>>  used namespaces
>>  > C - might work depending on having an implementation that knows when to
>>  > preserve not visibly used namespaces
>>  >
>>  > 2:
>>  > A: expensive
>>  > B: works
>>  > C: does not work
>>  >
>>  > 3:
>>  > A: works
>>  > B: works
>>  > C: does not work
>>  >
>>  > i.e. our current position works non-interoperably for XSLT in
>>  RDF - a use
>>  > case that we have not seen, and that is its only advantage over
>>  soln 3 which
>>  > interoperably does not work for XSLT in RDF.
>>  >
>>  > ====
>>  >
>>  > If we go for soln 2 or soln 3 we have to reconsider whether we wish to
>>  > preserve comments, and which not visibly namespaces we preserve.
>>  > I suggest preserve comments, and no namespaces that are not
>>  visibly used.
>>
>>  OK, this is your X choice.  Did DigSig group express a preference?
>
>exc-c14n - I do not have an axe to grind on the comments either way.
>
>>
>>
>>  From my experience, I think preserving comments will be tricky to
>>  implement on top of the C SAX API so slightly prefer not preserving
>>  them.  I will investigate, however.   I have no preference on the
>>  namespaces.
>
>If the comments are hard in some environments let's ditch them.
>
>>
>>  Is 3 still too lax for "removing implementation variability from RDF/XML"?
>
>Yes. Reagle says (in the same msg):
>"what purpose is a canonicalization even serving if you are
>likely to get implementation variances? "

I took this comment as a rhetorical question meaning, "why bother 
even getting into canonicalization if you have implementation 
variance?" and hence suggesting a fourth option, which you did not 
consider:

D. Ignore XML canonicalization and treat XML literals as strings, ie 
the L2V mapping is the identity.

Then the entire rdf:XMLliteral datatype machinery is just an 
elaborate way of encoding the old 'XML bit', which I thought was the 
original intent in any case. Introducing XML canonicalization seems 
to have been one those neat ideas that got slipped in without too 
much discussion and has turned out to be a tar-pit. I am particularly 
concerned that this ugly mess is now centrally included in the very 
core of RDF. I would hope that many 'cheap and cheerful' RDF engines 
wouldn't even want to know about XML, still less about XML 
canonicalization.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam
Received on Friday, 28 February 2003 10:00:47 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:55:54 EDT