MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fwd: [emergency-comment] CAP Normative Schema is improperly defined
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]