QNames and URIs (was Re: [dss] plans for next draft)

[Trevor Perrin <trevp@trevp.net>]

At 04:37 PM 11/18/2003 -0500, Rich Salz wrote:

> > 4)  Add a 'type' QName attribute to the <ContentTimestamp>,
> > <SignatureTimestamp>, and <ReturnUpdatedSignature> optional inputs.  This
> > allows these optional inputs to be extended, per Frederick's suggestion 
> [3].
>
>The W3C technical architecture group has a document on when and how to use
>QName's. We should make sure we're in complaince.  Better yet, why not 
>just use a URI?


After reading the TAG's doc [1] I agree.  We should probably use URIs more 
in general.

QNames have the advantage of being shorter, but they require a little care, 
cause you have to say how the URI-prefix is attached.  We've been including 
the text "A namespace prefix MUST be provided", which I think resolves that.

But it seems URIs are otherwise preferable, cause easier to process.

Below is a summary of our use of QNames.  I'll propose leaving the first 3 
as QNames, and replacing the last 2 with URIs.
  1) Result/ResultMajor, Result/ResultMinor
  2) SignedProperties, UnsignedProperties
  3) ProcessingDetails
  4) NameType/@Format
Proposal:
  5) Adding a 'type' attribute to ContentTimestamp, SignatureTimestamp, 
ReturnUpdatedSignature

For the 1st 3, I think QNames are reasonable:
  1) SAML and XKMS use QNames here, I guess just cause they're shorter
  2) These properties likely are XAdES elements, which are easy to refer to 
with QNames, i.e.: "xades:SigningTime".
  3) ProcessingDetails are based off XKMS's <ValidReason>, <InvalidReason>, 
<IndeterminateReason>, which use QNames, again probably just cause they're 
shorter.

But 4 and 5 should probably be URIs.


If this is reasonable, I'll do 4 and 5 as URIs in the next draft.

Trevor


[1] http://www.w3.org/2001/tag/doc/qnameids.html