OASIS Emergency Management TC

 View Only

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

  • 1.  Re: [emergency] Fwd: [emergency-comment] CAP Normative Schema isimproperly defined

    Posted 03-30-2004 13:31
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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]