W3C home > Mailing lists > Public > www-xkms@w3.org > March 2002

Re: namespaces are great...

From: Joseph Reagle <reagle@w3.org>
Date: Tue, 5 Mar 2002 13:33:10 -0500
Message-Id: <200203051833.NAA07698@tux.w3.org>
To: stephen.farrell@baltimore.ie, www-xkms@w3.org
On Tuesday 05 March 2002 12:45, Stephen Farrell wrote:
> Joseph was pure when he said:
> > For structural purposes, the ValidityInterval (and all KeyBinding
> > children) could be in a separate namespace.
> I've no idea about this one, except to ask: "why?"

For demonstration and extensibility purposes. The main thrust of my 
strawman [1] is that in XKMS we are doing three things (1) sending a query 
or response with a very light protocol (prefixed with prtcl:), (2) querying 
for some data (prefixed with sql:) where that data is some key structure 
(prefixed with dsig: or xenc:) *and* querying for (3) other structures 
which communicate other semantics about those key structures (prefixed with 

I'm not so concerned that all these have to have these particular prefixes 
-- or even different namespaces; I'm using it to demonstrate they are 
orthogonal pieces. However, on the trust stuff, I actually would like it to 
have its own namespace. I expect defining the meaning of the KeyBinding 
children will be the most difficult and confusing part (i.e. trust 
semantics, beware!) The protocol bit (request/respond) and the means of 
query (from/where/select) will be relatively straightforward. For the trust 
stuff, people will want to add their own semantics in time, we may want to 
correct mistakes or make improvements, and all of this can be done 
orthogonally. XKMS 2.1 could conceivable be XKMS 2.0 with all the same 
protocol and query stuff (even using the old namespace) but with a few 
additional tags, or improved definitions of semantics in a new "trust" 

Trying to address a design by abstracting and breaking down the constituent 
parts is always a good idea IMHO. For example, in xmldsig I wish I had been 
able to separate the "core" syntax and processing from the KeyInfo stuff. 
The "core" could've been implemented, interop'd and advanced much faster 
than it was; and we could've spent the time hammering on the semantics and 
tricky encoding issues that was needed. Instead, core was delayed, and 
KeyInfo includes bugs that it shouldn't.


[01] <prtcl:Request 
[02]    <sql:Query>
[03]      <sql:From URI="http://example.org/SomeXKMService/v1.1"/>
[04]      <sql:Where>
[05]        <ds:KeyName>Joseph</ds:KeyName>
[06]      </sql:Where>
[07]      <sql:Select>
[08]        <trust:KeyId/>
[09]        <trust:Status/>
[10]        <trust:Interval/>
[11]        <ds:KeyInfo>
[12]          <ds:KeyName/>
[13]          <ds:KeyValue/>
[14]        </ds:KeyInfo>
[15]      </sql:Select>
[16]   </sql:Query>
[17] </prtcl:Request>


Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Tuesday, 5 March 2002 13:33:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:38 UTC