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

Forwarding to the TC list for discussion....

Begin forwarded message:

> From: "Bob Wyman" <>
> Date: March 28, 2004 3:49:42 PM EST
> To: <>
> Subject: [emergency-comment] CAP Normative Schema is improperly defined
> Reply-To: <>
>
> 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

919.806.2440