W3C home > Mailing lists > Public > www-xkms-ws@w3.org > December 2001

RE: optional stuff (was Re: URL-level trust (was: Re: XKMS))

From: <edsimon@xmlsec.com>
Date: Mon, 3 Dec 2001 11:23:53 -0500
Message-ID: <3C053CF1000019A0@mail.san.yahoo.com>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 13:51:45 EDT