- From: Michael Kay <mike@saxonica.com>
- Date: Fri, 30 Jun 2023 19:13:38 +0100
- To: Ignacio Losiggio <ilosiggio@salesforce.com>
- Cc: xmlschema-dev@w3.org, APIKit Team <apikit@mulesoft.com>
It's generally the tradition in the XML family of specs to NOT be liberal in what you accept, but rather to require rejection of anything that isn't strictly within the rules. The XSD spec does NOT say "if the RFC allows it, then so do we". It refers to the RFC only to say that that's where the Base64 alphabet is defined. A processor that ignores other characters than those permitted, rather than flagging the content as invalid, is not a conformant XSD processor. That's a statement of fact rather than a value judgement. If people think there is a market for a piece of software that isn't conformant with the XSD specification, they are perfectly entitled to develop it and sell it; but they aren't entitled to misrepresent it. Michael Kay Saxonica > On 29 Jun 2023, at 20:45, Ignacio Losiggio <ilosiggio@salesforce.com> wrote: > > Hi! I'm trying to understand if a given behaviour is spec compliant or not. > > XML Schema Part 2 says: >> The lexical forms of base64Binary values are limited to the 65 characters of the Base64 Alphabet defined in [RFC 2045], i.e., a-z, A-Z, 0-9, the plus sign (+), the forward slash (/) and the equal sign (=), together with the characters defined in [XML 1.0 (Second Edition)] as white space. **No other characters are allowed**. > > But the corresponding RFC allows decoders to ignore any non-decodable > character. Should the XML Schema have a bigger priority at the expense > of compatibility with off-the-shelf base64 utilities? > > I've found an XML library that shows the MIME-mandated behaviour > instead of the XML Schema one [1]. It's probably not the only one. > > [1] https://github.com/xmlark/msv/issues/4 > >
Received on Friday, 30 June 2023 18:13:49 UTC