Fwd: [emergency-comment] CAP Normative Schema is improperly defined

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

Forwarding to the TC list for discussion....

Begin forwarded message:

> From: "Bob Wyman" <bob@wyman.us>
> Date: March 28, 2004 3:49:42 PM EST
> To: <emergency-comment@lists.oasis-open.org>
> Subject: [emergency-comment] CAP Normative Schema is improperly defined
> Reply-To: <bob@wyman.us>
>
> The normative XML Schema in the CAP specification is improperly 
> defined and will either generate validation errors or be rewritten to 
> a form which conforms to XML Schema when�input to�common�XML 
> Schema�processing tools. A major source of the problems is the fact 
> that what should be anonymous simple types in the CAP schema are 
> encoded with "name" attributes and are thus not anonymous. For 
> instance, the CAP schema defines the element msgType as:
> �
>
> <element name = "msgType">
> � <simpleType name = "msgType" >
> ��� <restriction base = "string">
> ��� ...
> ��� </restriction>
> � </simpleType>
> </element>
> �
> A proper definition of the msgType element would *not* include the 
> "name" attribute in the "simpleType" element. Thus, the proper 
> definition would be:
> �
>
> <element name = "msgType">
> ��� <simpleType>
> ����� <restriction base = "string">
> ����� ...
> ����� </restriction>
> ��� </simpleType>
> </element>
> �
> ���This improper use of XML Schema occurs at least 10 times in the CAP 
> schema (I may have missed a couple...)
> ��� Given that most well written XML Schema processors will rewrite or 
> reject the normative CAP schema, it is hard to understand the 
> justification for proposing a standard that contains a flawed 
> normative definition. In this case, for interoperability to be had, it 
> is necessary to assume that all XML Schema processors will either 
> ignore or rewrite the offending elements of the schema in a consistent 
> manner. While this appears to be the case so far, it introduces a risk 
> of interpretation that is not appropriate for a standard such as CAP. 
> For a standard such as CAP, it must be recognized that 
> misinterpretations of CAP messages can lead to life-or-death 
> consequences. Such a standard should only be�accepted if it has 
> achieved the highest possible levels of clarity and quality.
> �
> ������� bob wyman
> �
>
--
R. Allen Wyke
Chief Technology Officer
awyke@blue292.com
919.806.2440