Re: [xml-dev] A dandy little technique for constraining your stringsto A

[Wendell Piez <wapiez@wendellpiez.com>]

xml-dev,

I'm a big fan of layered validation, but I hasten to add two things (no, three):

1. Although it may help to formalize interfaces in a way that might be
useful (for the only thing that really matters, negotiation), the idea
doesn't really, despite Rick's characterization, address Postel's Law,
which is not about how to design or build, but about how to work in
the space where a formal or nominal design has failed. Where, for
example, the spec says "use a URI" or "use ASCII", without managing to
define clearly what that should be taken to mean. Whether to be
"conservative" or "liberal", in such a situation, should depend on
whether one is producing or receiving. But the very line between "what
should work" and "what shouldn't" is at issue only because it can
depend on who is doing the working.

When we can agree on what "URI" or "ASCII" or what-have-you should
mean, we have no problem. It's where we don't, that the principle of
"do unto others as you would have them do unto you" really becomes
important. (That would be an older formulation that amounts to the
same thing.)

2. Given this, it rankles me to hear that XML, for example, fails to
observe Postel's Law, because it mandates draconian error handling.
("Not only is XML mean to me, it makes me be mean to others.") This is
a non sequitur and the fact is the opposite. Because we have DEH
(among other reasons), the occasions where it is ambiguous whether
something is or is not XML, and of what sort, as presented to a
parser, are really quite rare. (Here we leave aside philosophical
issues as to whether XML is "really the model" or "really the
serialization", and address only the latter. Indeed the very fact that
we can reasonably suppose it is "really the model" is due to the parse
working as well as it does.) This narrows the murky grey in-between
zone where Postel's Law is the only thing we have to go on, at least
as far as it concerns XML, or at any rate, XML-as-XML. We just don't
have to fight over it.

3. Layered validation, similarly, is not a solution to the problem of
how to follow the so-called "Robustness Principle" (or how to know,
suppose or claim we are following it), but rather a strategy for
managing when we are likely to need it. The problem itself, considered
generally, does not admit of a formal, principled solution, and
cannot, precisely because it appears only in conditions of failure --
and we never know where those might occur, especially as the rules
become more complex and more players take to the field.

Regards, Wendell



On Thu, Oct 22, 2015 at 5:04 AM, Michael Kay <mike@saxonica.com> wrote:
>
> On 22 Oct 2015, at 01:29, Rick Jelliffe <rjelliffe@allette.com.au> wrote:
>
> If the schema is a published interface for a large system, rather than some
> changeable part inside a black box, then you should consider having a two
> layer schema.
>
>
>
> One idea I have been trying to develop is the idea of a “parameterized
> schema” where parameters supplied at validation time affect the constraints
> that are applied.
>
> I’ve made a start with this by allowing XSD 1.1 assertions to contain
> variables bound to parameters that can be supplied at schema validation
> time. But it could go a lot further, for example
>
> <pattern value=“\p{isBasicLatin}” use-when=“$conservative”/>
>
> Of course, it’s easy enough to implement this yourself with a preprocessor.
>
> Michael Kay
> Saxonica
>



-- 
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^