OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [security-services] Additional comments on core-02

Scott Cantor wrote:
>>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.

But in practical terms, we need to give a clear signal to implementors 
about what to "respect".  Maybe we need to make double-sure that we 
never get the prose wrong in describing the schema effects (I tried to 
do a thorough job prior to cd-01 but it may have gotten out of sync 
again or I might have missed something).  But it's impractical to tell 
people, "If the difference favors tighter constraints in the prose than 
the schema, use the prose; if it favors tighter constraints in the 
schema than the prose, use the schema!"

Come to think of it, I suppose we could say that the "tighter 
constraint" is always in force, but then I'd worry that the meaning of 
"tighter" requires interpretation...


Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]