RE: [emergency] Namespace

["Bob Wyman" <bob@wyman.us>]

Rex Brooks wrote:
> A standard XML Schema Validation Service would be a fine
> help to start, but it would have to be verified as validating
> standards that demonstrably work successfully with the major
> web stacks, but most especially with the stacks that represent
> the vast majority of market share on the web, Apache with 
> ~62-67% and Microsoft ~22-27%:
	No, No, No!
	This would be good thinking if you were writing a product, but
this isn't a product. CAP is a *Standard*! It requires a different
kind of thinking.
	When writing a standard you must, as Len Bullard said, be
"tediously correct." This means that your normative clauses *must*
conform to the normative clauses of the standards that you reference.
Thus, if XML Schema says that local simpleTypes MUST NOT have "name"
attributes, then CAP MUST NOT be defined to use them even if *no*
software exists that can handle local simpleTypes without name
attributes.
	The reason for this is that standards "live forever" while
products are ephemeral. Standards define laws. Products do not.
Products come and go and change their capabilities from release to
release. There is always a tension between products and standards.
However, those who write standards best serve their constituencies by
writing their standards in the most unambiguous form possible. This
means that you must write every sentence with the precision that a
lawyer would and you must read every clause of your referenced
standards as though they were law. Only by following this method can
you hope to have consistent interpretations of standards.
	In the rare case that it is necessary to depart from an
existing standard, the correct way to do this is to either produce a
"profile" of the inadequate standard or, if the issue is product
specific, produce a non-normative implementation guide that
unambiguously explains how the standard is to be interpreted by users
of the product.
	You could, for instance, produce a profile that defined a
"CAP/XML Schema Language" which extended the XML Schema syntax to
include "name" attributes on local simpleTypes. However, doing this
would mean that standard XML Schema processors would not be able to
work with the CAP/XML Schema. This would also mean, of course, that
the Emergency TC would now "own" a standard with all the complexity of
XML Schema... Not a good thing. Doing something like this is rarely
the right thing to do.
	The more reasonable approach is to recognize that some set of
processors that have *bugs* that prevent them from processing Schemas
that conform to the XML Schema of Schemas. In this case, if Axis is
the offending processor, one could write a non-normative
implementation guide that defined exactly how the properly defined
normative XML Schema should be modified to address the bugs and
limitations of the offending processor. This might be done by
providing a non-normative restatement of the CAP Schema or by
producing something like an XSL template that deterministically
transforms the normative schema to one that the offending processor
can process. However, the XML Schema conformant version of the CAP
schema must always be the single normative expression of CAP.
	Sometimes, if you're lucky, you'll discover that a standard on
which you are dependent offers more than one way to accomplish some
purpose. And, you'll discover that popular or important processors of
the format are capable of handling one method but not the other. In
this case, it is sometimes appropriate to allow this knowledge of the
limitations of existing processors to push you to prefer one method
over the other. As long as there is an alternative that doesn't
compromise your ability to express your standard clearly and
unambiguously, it is ok to choose the alternative that is more
supported. However, this is *not* a slippery slope that leads to
adopting non-conforming syntax. You MUST stop this accommodation of
broken processors at the moment that such accommodation either
compromises the clarity of expression in your standard or at the point
where further accommodation requires violation of the referenced
standard.
	Naturally, in the context of product building, not standards
defining, these rules are completely different. When building a
product, one typically tries to be as accommodating as possible. But,
we're not building a product here...

		bob wyman