W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

RDF & enveloping of XML structures

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Mon, 4 Mar 2002 11:49:03 -0000
To: <w3c-rdfcore-wg@w3.org>, <w3c-ietf-xmldsig@w3.org>

This is the first of too many messages about the two issues to do with
rdf:parseType="Literal" and XML Canonicalization.

Last week, the RDF Core WG agreed to use XML C14N as the basis for
addressing two of its outstanding issues:

On this basis, I had a worthwhile conversation with John Boyer at the
plenary, and I am now trying to take the issues through to conclusion,
partly on the basis of John's input.

I am cross-posting to both groups, and using RDF as the first words of the
subject line on all messages. I hope this will allow the people who are not
interested in this application of XML Canonicalization to ignore the
relevant threads.

This message will give an overview of the other messages, and an overview of
the choice space.

RDF & XML Literals: Intro

An introduction to the issue for people unfamiliar with RDF.
Also identifies the problems with the current position as specified by the
RDF Model & Syntax Specification
Also introduces the issues:

RDF XML Canonicalization Intro
Intended for the RDF group, summarising C14N and XML subsets.

RDF C14N Comments  (A)
Discussion of XML comments in C14N, and xml-literals in RDF.

RDF C14N Inclusive or Exclusive (B)
Discussion of the differences between the two C14N specs.

RDF C14N InclusiveNamespaces (C)
Discussion of this aspect of C14N exclusive.

RDF C14N XML Literal Equality (D)
Should C14N be used to describe the processing of rdf:parseType="Literal" or
only in the definition of XML Literal equality.

RDF C14N Max or Min (E)
Should the new RDF specs try to maximally or minimally specify the behaviour
of RDF processors w.r.t. rdf:parseType="Literal"

RDF C14N sketch of text
An idea of what text in our new specs might look like.
This will also indicate my preferred resolution.

RDF C14N proposed resolution
For consideration by the chair for a forthcoming telecon.

The intent is that the issues labelled (A) - (E) are all binary. (A) - (D)
have only one internal constraint, that the InclusiveNameSpaces are only
significant if we use exclusive canonicalization. Hence (A)-(D) described 12
possible positions, none of which is completely stupid or incoherent.

(E) is intended as a binary choice at a higher level, that, if we can decide
on that, will help us to make a philosophically consistent cut through
issues (A), (B) & (D).

That is, I see a choice space with 12 options. Deciding on (E) first will
mark two or three of these twelve options as preferred, and hence make the
subsequent choices easier.

I will try and write these messages today, but some might hand over until

Received on Monday, 4 March 2002 06:49:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC