Re: C14N .vs. XML Schema

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.

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.  Consider the example of a purchase order 
document sent to a secure site that provides commerce services.  The site 
is documented (perhaps on a web page at its side, perhaps using some other 
means) as accepting purchase orders corresponding to the schema 
(http://commercesite.com/purchaseOrder.xsd) for the target namespace 
http://commercesite.com/purchaseOrder. 

Now, let's say I send them a purchase order that looks like this:

<purchaseOrder xmlns="http://commercesite.com/purchaseOrder"
        xmlns:xsd="..the usual.."
        <!-- Noah says: use my bogus schema instead -->
        xsd:schemaLocation="http://commercesite.com/purchaseOrder
 http://donttrustme.com/purchaseOrder.xsd"?

        ... contents of purchase order here...
</purchaseOrder>

Surely this high-volume commerce site does not want to validate against 
some schema that I made up for their namespace; on the contrary, it 
probably does not even wish to open a connection back to my site. 
Furthermore, the fact that my document validates against my schema is of 
almost no use to the receiving application

The XML schemas design allows the implementor of the commerce site to 
acquire and use conforming processors that implement policies according to 
his or her needs.  For example, the processor could completely ignore the 
schemaLocation hint.  Alternately, it could check the supplied location 
and register,  noting that the user has explicitly called for a schema not 
known to match the required one.  Indeed, the commerce site might enforce 
a convention that xsd:schemaLocation must be supplied, and must match the 
expected schema; the site could buy or build processors that would do the 
required checking, or could do it in the application above the processor. 
Eventually, conventions might be developed for creating checksums to 
govern only the schema constructions overtly affecting content, or other 
semantics of the schema as well.  This could be done as an industry 
standard, or privately within some particular community of XML users. 

The point is that the current schema design allows one to build conforming 
processors that support all of these usage models.  If you and the people 
you work with wish to rely on xsd:schemaLocation, then by all means 
document its use as mandatory for your applications, and insist that 
people building such applications use processors that unconditionally 
follow the xsd:schemaLocation.  That behavior too is supported by the 
draft.

Note that XML schemas intentionally avoids specifying a fixed API for 
invoking processors.  When and if such a standard is undertaken, 
processors will become more plug compatible.  Such a standard will need to 
account for common conventions for locating and checking schema documents, 
such as the ones discussed above. 

Default values are not the only aspects of the schema that potentially 
cause trouble.  Let's say that two schemas were constructed for the same 
namespace: the first one typed and attribute ATR as integer, the second 
one type the same attribute as string.  Now let's imagine a future version 
of XSL that uses an XPath extension to match on integers and format all of 
them in italics.  Clearly, the formatting of the results will depend on 
the version of the schema that was used. 

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.

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

Received on Wednesday, 30 August 2000 15:35:23 UTC