Re: [emergency] Namespace

[R. Allen Wyke <emergency-tc@earthlink.net>]

I wholeheartedly and 200% support every single thing you point out 
here! You have elegantly  described, all in one email, the horse I have 
been riding about ambiguity, making sure the spec and XSD agree, etc. 
CAP, in and of itself (element A, element B, whatever), is not the 
issue (well, it is an topic, but not what I am talking about here). I 
think the basic structure is fine - it works, but not my issue. It is 
the method in which we actually define CAP and "how" we go about that. 
"How" well we craft the document that describes the spec - how well we 
write the standard if you will.

Standards and products are different, and your description of the 
separation could not be more true. And as for this comment:

> 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.

That is exactly what we (Blue292 speaking here) have to do, because 
recieving, sending, processing, and displaying the content in an alert 
can vary widely across implementations. I HATE that we have to do that, 
because it all of a sudden feels proprietary, but there is no way 
around it. It is the only way we can have any assurance that our 
platform can interoperate with E Team, DMIS, NWS, whoever - we have to 
put a stake in the ground and say, "well, we do it this way." And that 
level of interoperability is the very basis of why this TC was formed, 
and therefore should (maybe an RFC 2119 MUST is the right word here :) 
be a part of any work product we produce.

On Mar 31, 2004, at 12:24 PM, 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
>
>
--
R. Allen Wyke
Chief Technology Officer
awyke@blue292.com
919.806.2440