Re: [emergency] Namespace

["CONSULTRAC" <rcarlton@consultrac.com>]

Just to add my support; if the elemental component parts of a spec aren't
specifically defined and subsequently "required" it ain't a standard. Good
on ya guys!

R
----- Original Message ----- 
From: "R. Allen Wyke" <emergency-tc@earthlink.net>
To: <bob@wyman.us>
Cc: "'Rex Brooks'" <rexb@starbourne.com>; "'Gary Ham'" <hamg@BATTELLE.ORG>;
"'Art Botterell'" <acb@incident.com>; "'Kon Wilms'"
<kon.wilms@ndsamericas.com>; "'Emergency TC'"
<emergency@lists.oasis-open.org>
Sent: Wednesday, March 31, 2004 9:40 AM
Subject: Re: [emergency] Namespace


> 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
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
>
>
>