- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 17 Apr 2009 14:19:27 +0300
- To: Robin Berjon <robin@berjon.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, ext Jonas Sicking <jonas@sicking.cc>, "marcosc@opera.com" <marcosc@opera.com>, Thomas Roessler <tlr@w3.org>, public-webapps <public-webapps@w3.org>
On Apr 17, 2009, at 13:24, Robin Berjon wrote: > Trying to separate the discussion from the change request: would you > be satisfied if requirements to perform C14N were removed and > reliance on XSD data types for definition purposes were replaced > with something less scary (though in this case this is a bit of a > FUD argument Henri, the referenced types aren't overwhelming)? My preferred change would be adopting jar signing. However, if that's not feasible, my next preferred option would indeed be removing the requirement to perform canonicalization (i.e. sign XML as binary with a detached traditional binary signature block). As for the data types, I'd be satisfied if the datatypes were defined in such a way that attribute value parsing algorithms and conversion methods that a browser engine has to contain anyway were reusable. This should include well-defined behavior in the case of non- conforming input. For example, for dates (which is a datatype that widgets add--not something that comes from XML signatures), it makes more sense to reuse an appropriate microsyntax definition from HTML5 than to delegate to XSD. XSD not only makes leading and trailing whitespace conforming and fails to define behavior in the case of non-conforming dates, XSD which even allows leap seconds! (Is it a FUD argument that XSD dates deviate from the value space that is typically used in Posix date conversions between multi-unit tuples and epoch seconds?) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 17 April 2009 11:20:20 UTC