Hi Rich,

You’re right one could deal with the issue in prose.  Currently, it works through negation, e.g., “The <RespondWith> element in the request specifies…included in the request…”; and in other places in the spec, except here and except there, etc.  The issue is that if one states the element SHOULD be encoded in a request, then the reader has to sift through all the negations to determine what it really means; which (imo) is not the RFC[2119] intent of SHOULD.

So…if you define the request ‘types’ that encode RespondWith in Binding Section 3.2.3 you do clarify w/o changing schema.  Then the negation aspects are redundant *for* clarity (which I do not object).

You could remove RespondWith from RequestAbstractType w/o creating a new abstract type, but it requires that you add RespondWith to each type that encodes it.  That’s why I suggested defining a new abstract type just to be concise.  The wire format will not change in either case so ( rhetorically) why should an existing processor or client break? 

--------- Original Message --------
From: "Rich Salz" <rsalz@datapower.com>
To: "Matt Long" <mlong@mvsquared.net>
Cc: www-xkms@w3.org
Subject: Re: Schema Issue
Date: 24/05/05 08:10


Another way to look at this is to refactor RequestAbstractType to make
it more clear.

This would be nice, but I don't see it as a MUST for moving forward.
Much of the semantics are already embedded in the prose. :)
/r$

--
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http://www.datapower.com/products/xs40.html