Looking at the recent discussions, it seems there has been a push
toward making as much optional and configurable as possible. I think
this is basically healthy -- I've been pushing it on a couple of issues
myself -- but I would like to try to take stock. After all, at some
point we have to specify something.
I'm sure there are well-known methodologies for doing this, but I
don't know them. Until a more specific process comes along, I'll
define these broad categories:
- Core: Essential requirements that MUST be followed. E.g., the
Subscribe request MUST fault if the subscription could not be created.
- Optional, specified: Features that MAY be implemented. If they
are, they MUST be implemented the way we say. E.g., GetCurrentMessage
- Partly specified: Features which MUST be present in some form.
We specify (or point to) and possibly RECOMMEND some alternatives, but
implementations may use their own. E.g., topics MAY follow WS-Topics.
- Open: Features which MAY be present, but we specify nothing about
what they look like if they are (MUST doesn't really mean anything if
the content is arbitrary). E.g., Precondition, QoS guarantees,
security parameters . . .
Again, I'm open to better and/or more standard names.
I would like at some point to pull together a table of major features
and categorize them both in draft 04 and the decoupled draft. But the
issues I'd like to raise here are:
- Do we prefer a mechanism or mechanisms for specifying where a
particular implementation stands with respect to all this optionality?
E.g., do we require that an implementation use WS-Policy to specify,
say, what QoS it provides for delivery?
- Where do we provide defaults (changing from "open" to "partly
specified")?
- For what optional features do we want to specify particular
alternatives? We have done so for topics and for delivery
(WS-BrokeredNotification). Are there other such areas?
- Which features really are core? I had thought, for example, that
at least the use of WS-Addressing to specify endpoints was core, but
even this may not be. I don't mind this per se -- I could see this as
partly specified, with WS-A as one alternative. I'd just like to keep
track of what's core and what's not.
I suspect this may stir some discussion and debate over what belongs in
which category. That's fine, too. However, I'd also like to try to
pull together summaries from time to time in order to maintain a larger
perspective.
|