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 Schemaisimproperly defined


I'm not sure we can answer that except in practice and collect our 
experience into that implemention guide I'm having a tough time 
getting to.

The landscape of xml schema validation is a minefield littered with 
the remains of schemata and applications that have married themselves 
to a single interpretation represented in a particular tool, such as 
XML Spy. The fact is you can get different validation results with 
different tools, so for the time being you have to either choose one 
that most of your target audience uses if there is one, or else go 
for a solution that works across the widest range of validators and 
platforms.

That means you need to consider that the overwhelming predominance of 
web servers run on vanilla BSD using Apache, so the notion that a 
problem is an Axis or other java tools issue seems to indicate a 
bias, and if ones follows that track one could be buying trouble. I 
really don't see a lot of value in getting into the XML battles or 
the tools battle that falls out of that. We ran into in a similar 
situation in WSRP when folks from some of the top tier vendors 
clearly wanted to run with UDDI without even noticing ebXML, then got 
caught up short when it got noticed by the proponents of ebXML--which 
includes a whopping whole lot of the rest of the world. So I really 
don't see much value in getting into the international (ISO-ANSI-US 
Feds) standards v. business based (W3C) standards arguments. Been 
there, done that, got the scars (from both ends of the argument) to 
prove it.

Now, having said that, I agree with Gary that strong typing makes the 
most sense to me, and tends to avoid that whole issue mentioned above.

Ciao,
Rex

At 8:46 AM -0500 3/30/04, R. Allen Wyke wrote:
>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
>
>
>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.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request


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