- From: <Noah_Mendelsohn@lotus.com>
- Date: Mon, 26 Mar 2001 23:34:33 -0500
- To: "Brian LaMacchia" <bal@microsoft.com>
- Cc: reagle@w3.org, w3c-ietf-xmldsig@w3.org, xmlschema-dev@w3.org
Brian LaMacchia writes: >> CryptoBinary and base64Binary are not exactly >> equivalent -- there are further restrictions >> on a CryptoBinary because it is a representation of >> a single bignum This is exactly the sort of thing I had in mind when I suggested that higher level application or library software could key on the "CryptoBinary" type name to do the additional validation. Indeed, I think that some have failed to notice that the schemas design in this respect anticipates layered families of type libraries and associated schema processors. Core compatibility is what we describe in the schema specification, and everyone must implement it compatibly. On the other hand, someone might want to propose a higher level standard for math-oriented processors that will additionally recognize and validate a library of math types including perhaps a "PrimeNumber" type (which might be declared in the schema as merely a nonnegative integer). When presented with the same schema and document, an ordinary XML schema processor would validate the content as an integer, and would correctly report its type name as PrimeNumber. Similarly, a processor, library, or application with knowledge of digital signatures could recognize and do the additional validation of "CryptoBinary". Processors which merely conform to the XML schemas recommendation would correctly validate the content as base64Binary and would correctly report the type of any such element as "CryptoBinary". So, I think this further supports the suggestion that the additional type be retained. ------------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 Lotus Development Corp. Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------------
Received on Monday, 26 March 2001 23:36:30 UTC