> We put in notes for these because we advertised in V1.1 that they were
> going to come out in V2.0 in backwards-incompatible fashion. I can see
> an argument for removing the notes since we also did a lot of other
> invasive stuff between then and now.
Fine by me, I was just noting a difference between "remove with no
replacement" and "replacement".
> We hadn't wanted to use wording saying the (non-schema-snippet) prose
> literally "takes precedence", but in fact that's the only practical
> solution when we have these added constraints. What we've got is
> therefore confusing.
It takes precedence, but only in the sense that something might be permitted
by the schema and not permitted by the text, and is therefore not permitted.
In the majority of cases, I think we've avoided that, but a couple still
exist. And we probably should try and identify them and make sure they stand
out.
But the oppposite isn't true...if it's outlawed by the schema, the text in
no way should be construed as to permit it. And the problem with English is
that it's hard to be precise, and I just don't want to convey the impression
that one can understand the syntax without a working knowledge of XSD.
We could have used RELAX, etc., and I'm not taking a position on the
wonderfulness or lack thereof of XSD, but it's what we used.
> However, the normative text in this specification provides the
> authoritative interpretation of all SAML semantics and processing. (In
> some cases, the text deliberately defines constraints that go beyond those
> expressed in the schema documents.)"
I'm a little uncomfortable with the looseness of that in terms of not making
clear that while we sometimes outlaw schema-valid XML, we never "inlaw" ;)
schema-invalid XML.
-- Scott
