RE: [emergency] Namespace

[Rex Brooks <rexb@starbourne.com>]

I hear you, and I actually don't disagree with you. That may seem 
like a contradiction, but it isn't. What you describe as a more 
reasonable approach is fine with me.

Ciao,
Rex

At 12:24 PM -0500 3/31/04, Bob Wyman wrote:
>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


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request