- From: <edsimon@xmlsec.com>
- Date: Mon, 3 Dec 2001 11:23:53 -0500
- To: www-xkms-ws@w3c.org
In the XML Encryption WG, the prime directive was that a very strong case had to be made for any functionality requests. Essentially, if it could not be shown that a proposed feature was essential to the spec or could not be handled at the application level, then the feature was rejected. Not made optional, but rejected. Fact is, making a feature optional doesn't reduce the effort it demands of the WG. The basic idea is to keep it simple, and let experience prove that the design was too simple. If experience proves certain additional features need to be incorporated, then add them in the next version. Though there is the risk that adding a feature later may mean it cannot be added as cleanly as if it was added earlier, the risk of encumbering a spec and its WG is generally far greater. It is important to keep in mind XML is designed to make it easier to incorporate other namespaces (associated with other functionality) into the project at hand. The thing to remember is that it is not just easier for the XKMS WG to incorporate other namespaces but also for apps and other specs that might use XKMS. Therefore, always consider whether it really is better for XKMS to handle functionality X or whether it can be handled better higher up in the food chain. Start with an assumption of guilt, that proposed feature X is guilty of being UNnecessary to XKMS. The let the proponents of feature X prove beyond a reasonable doubt, not just a balance of probabilities, that feature X really is necessary. In all of this, don't take it personally if your feature doesn't get in. I didn't get certain features into XML Encryption v1.0 that I wanted either, but overall, the prime directive of starting with an assumption of non-necessity has worked well for XML Encryption. Ed -- Original Message -- > >Changing the subject line's becoming a habit, but I want to >separate threads. Mike's text (below) suggests defining an >element that allows the client to identify itself to the >responder. Now, that's fine (and can be discussed on the >other thread), but I can't see us insisting that that field >is always filled-in, - if we added it, it'd most likely >be "optional". > >So, my question is about optional fields - what should our >attitude be to these? IMO, the presence of optional fields >in other specifications has caused problems (less interop, >more complex specification), but has also provided a way >to reach concensus (or maybe just push things under a >carpet). > >I'd love to have a rule of thumb, specific to our situation, >that we can apply as folks suggest their favorite feature be >added as optional (as we all will:-). > >Anyone care to suggest such a "rule"? > >Stephen. > >> Such an identifier could arguably just be included in the URL, e.g. >> http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential?name=Mike_Just >but it seems more >> reasonable to add a separate element (in case the name exceeds the length >of URL accepted by some >> servers). Although I use a personal name in this example, this name might >be the name of an >> application (as Jeremy highlights above or the name of a role). > >-- >____________________________________________________________ >Stephen Farrell >Baltimore Technologies, tel: (direct line) +353 1 881 6716 >39 Parkgate Street, fax: +353 1 881 7000 >Dublin 8. mailto:stephen.farrell@baltimore.ie >Ireland http://www.baltimore.com > > ----------------------------------------------------------------------------------------------- Ed Simon XMLsec Inc. Interested in XML Security Training and Consulting services? Visit "www.xmlsec.com".
Received on Monday, 3 December 2001 11:24:15 UTC