W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2004

Re: Importing xmldsig-core stuff...

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 28 May 2004 10:56:01 +0100
Message-ID: <40B70CB1.3030105@cs.tcd.ie>
To: Joseph Reagle <reagle@w3.org>
Cc: w3c-ietf-xmldsig@w3.org, "Nystrom, Magnus" <magnus@rsasecurity.com>


Thanks Joseph,

That's the change we've decided upon.

Regards,
Stephen.

Joseph Reagle wrote:
> On Tuesday 25 May 2004 12:56, Stephen Farrell wrote:
> 
>>The RFC editor pointed out that their schema checker objects to
>>the schemaLocation value above since they don't have a dsig
>>core schema at that relative location.
> 
> 
> That sounds approriate.
> 
> 
> 
>>The schemaLocation attribute is however just a hint [2], so the
>>schema passes using the checker on the w3c site.
> 
> 
> Yes, though if you do use it, the Schema spec says [b] "When a 
> schemaLocation is present, it must contain a single URI reference which the 
> schema author warrants will resolve to a serialization of a ·schema 
> document· containing the component(s) in the <import>ed namespace referred 
> to elsewhere in the containing schema document." 
> 
> [b] http://www.w3.org/TR/xmlschema-1/#composition-schemaImport
> 
> 
>>So, the question:-
>>
>>- is it ok as is?
> 
> 
> A non-working hint doesn't seem appropriate to me, why would you use it?

To debug the RFC editor's processes of course:-)

> 
> 
>>- should I change the value of schemaLocation to use an
>>   absolute URL, in particular [3]?
>>
>>I assume the latter is better.
> 
> 
> Yep, the only way it wouldn't is if somehow one interpreted the URL as a 
> secure string/identifier. For example, there's some program that will only 
> use schemas that when they import from dsig, import that specific string, 
> and not the URL. But I'm not aware of any such processing, and the W3C 
> never indicated "../W3C/xmldsig-core-schema.xsd" is a blessed 
> string/identifier -- unlike other algorithm identifier URIs where we use an 
> absolute URI.
Received on Friday, 28 May 2004 05:52:10 UTC

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