Re: C14N .vs. XML Schema

>> I18N and C14N are different.  I18N stands 
>> for Internationalization. C14N stands for 
>> Canonicalization, which is closely related 
>> with digital signature.

How embarrassing, of course I know the difference.  I have no idea what I 
was thinking.  Sorry.

Responding to your further comments below:  if you are referring to XML 
canonicalization as proposed in [1], then it seems implicitly to refer 
only to completely self-contained well formed documents.  I think it is 
the case that I might have two different DTD's, each providing different 
default values for the same attribute, and the proposed canonicalization 
has no explicit architecture for dealing with this situation.  Whether 
that is a good or bad thing is a different question (see below) but I 
think that is the status quo.  Now, [1] takes as its input an 
XPath-compliant data model, which might or might not have resulted from 
applying either schema or DTD defaults, but certainly I am aware of no 
proposal on the table that would standardize the process of applying 
defaults and then doing the canonicalization.

More fundamentally though, I think one has to ask why canonicalization is 
being used in any particular circumstance.  Implicitly, [1] is focused on 
providing a canonical representation (and let's assume supporting a 
digital signature) on just the instance document itself.  Sometimes that 
is what you want to do, and [1] does it.  As you suggest, there are 
circumstances in which you want to cover the effective content (with 
defaults, etc.) as opposed to be explicit content of an instance; by all 
means, the requirements for such circumstances should be articulated, and 
the appropriate canonical forms and signatures should be defined.  These 
would be canonical forms and signatures defined over pairs of {instance, 
DTD} or {instance, schema} I don't think there is anything in XML schemas 
that very much complicates the process of signing the combination of a 
document and the pertinent parts of the schema beyond what would be 
required to sign the combination of an instance document and a DTD. 
Indeed, as I suggested below, I think that digital signatures over such 
pairs (or at least over the pertinent parts of the schema itself) are a 
useful way to ensure that the sender and receiver have made compatible 
assumptions about the schema.

In any case, I certainly apologize again for my boneheaded misreading of 
I18N as C14N.

[1] http://www.w3.org/TR/xml-c14n

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------







Murata Makoto <mura034@attglobal.net>
Sent by: www-xml-schema-comments-request@w3.org
09/03/00 12:43 PM

 
        To:     www-xml-schema-comments@w3.org
        cc:     mura034@attglobal.net, (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject:        Re: C14N .vs. XML Schema

Noah_Mendelsohn@lotus.com wrote:

> I do not see why defaulting of a potentially localized value (red vs. 
> rouge) is particularly more troublesome than defaulting some other value 

> (1.0 vs. 2.5).  If you mistakenly switch schemas and get the wrong 
value, 
> you are in big trouble either way.  I don't think this has anything 
> specifically to do with internationalization.

I18N and C14N are different.  I18N stands for Internationalization. C14N 
stands for Canonicalization, which is closely related with digital 
signature.

> To reiterate a point that has been made before in public discussions, 
the 
> flexibility provided by the proposed schema design reflects the use of 
> validation as a service to the receiving application as well as to the 
> originator of the document. 

snip

> So, various communities will indeed want to adopt standards and 
> conventions for locating and identify schema documents; 
xsd:schemaLocation 
> is a tool that will be useful to some of them.  After long debate, the 
> schema workgroup came to the conclusion that providing flexibility to 
meet 
> the needs of different applications and processors would allow our 
> specification to be used in far broader range of circumstances that 
would 
> otherwise have been the case; we did that with full understanding that 
> default values and other information set contributions must be treated 
> with care.

I appreciate your detailed explantion.  However, I am not satisfied.

Suppose that I want to use digital signature for a purchase order. 
Also suppose that you want to use your schema for this purchase 
order rather than my schema. 

In my understanding, we are stuck.  When I create digital signature 
in my environment, I use my schema.  It might have default values 
and some other info which affects information sets.  Since you want 
to use your schema in your environment, you cannot use my digital 
signature.  We have to give up either "the flexibility provided by 
the proposed schema design" or digital signature.

Cheers,


Makoto
 
Internet: mura034@attglobal.net
Nifty: VEQ00625

Received on Tuesday, 5 September 2000 15:05:39 UTC