OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency] Fwd: [emergency-comment] CAP Normative Schema isimproperly defined


Gary, thanx for clarifying the actual issue you came across.

Bob, Kon, Gary, et al: I have a question. Is this an issue with Axis  
(and potentially other Java development/assistance tools), or two  
different interpretations of the XML Schema spec (aka it wasn't clear  
on how to implement)? I would imagine we would want the normative XML  
Schema to be "correct" (well-formed and validated against the XML  
Schema schema).

Allen

On Mar 30, 2004, at 8:09 AM, Ham, Gary A wrote:

> Kon, can you pass this on to the list since my mail seems to bounce  
> all the time.
>
> The reason for naming all types, including simple types, was two-fold.
> 1. Other tools, particularly the Axis based tools we were using for  
> generating SOAP encoding skeletons/stubs from the schema, were choking  
> on any unnamed type. I suspect that your quick-fix would work for us  
> as well.
>
> 2. The justice schema, to which we have informally agreed to keep  
> "in-mind" as we do our work, has no anonymous types, and goes so far  
> as to name instance usage of some item that would appear to be usable  
> as simple types.
>
> In general, strong typing for standards is a good idea,  I would not  
> object to actually adopting Kon's quick fix, if necessary.
>
> R/S
>
>
> Gary Ham
>
>
> -----Original Message-----
> From: Kon Wilms [mailto:kon.wilms@ndsamericas.com]
> Sent: Monday, March 29, 2004 5:02 PM
> To: R. Allen Wyke; Emergency TC
> Subject: RE: [emergency] Fwd: [emergency-comment] CAP Normative Schema  
> isimproperly defined
>
> Some info from my side -
>
> Windows Borland tools for processing XML (the XML to recordset  
> translator
> for C++/Delphi/etc.) require that simpletype be translated to  
> complextype.
> This is a 'quick fix' but seems to work. For .NET, one of our guys is
> rewriting the schema to make it work. There were also some case typos  
> in the
> 1.0 spec (simpletype vs. simpleType - strongly 'typed' parsers such as  
> the
> latest .NET version will not validate the schema when case is  
> incorrect).
> All of these use the MSXML DOM.
>
> Cheers
> Kon
>
>
> -----Original Message-----
> From: R. Allen Wyke [mailto:emergency-tc@earthlink.net]
> Sent: Monday, March 29, 2004 1:08 PM
> To: Emergency TC
> Subject: [emergency] 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
>>  
>>
>
>
> *********************************************************************** 
> ************
> Information contained in this email message is intended only for use  
> of the individual or entity named above. If the reader of this message  
> is not the intended recipient, or the employee or agent responsible to  
> deliver it to the intended recipient, you are hereby notified that any  
> dissemination, distribution or copying of this communication is  
> strictly prohibited. If you have received this communication in error,  
> please immediately notify the postmaster@nds.com and destroy the  
> original message.
> *********************************************************************** 
> ************
>
> 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.
>
>
--
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]