[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] EDXL DE - XML Schema Issue
I am concerned that what we have put together is not yet ready, and that we are taxing those that have volunteered to put the final touches on our work too heavily. Do we want to create a situation, like we did with CAP 1.0, where something important gets dropped? Personally, I would rather wait one more month than get it wrong in some minor, but potentially embarrassing, way. Right now, I intend to vote for the committee draft, but not for the release for vote. My mind could be changed if, in fact, a final product is ready and usable as an example before the voting deadline. I am afraid, however, that we do not have time to do the quality control review needed to get it all right before we put or product out for public inspection. Respectfully, Gary A. Ham Senior Research Scientist Battelle Memorial Institute 540-288-5611 (office) 703-869-6241 (cell) "You would be surprised what you can accomplish when you do not care who gets the credit." - Harry S. Truman -----Original Message----- From: Renato Iannella [mailto:renato@nicta.com.au] Sent: Tuesday, November 08, 2005 11:02 PM To: Emergency_Mgt_TC TC Subject: [emergency] EDXL DE - XML Schema Issue There are a few major/minor issues with the XML Schema used in EDXL DE CD 1.0 (19 Aug 2005). Major: 1 - It does not support ANY reusability as all the elements and datatypes are locally defined. (Common datatypes should be globally defined and reused, for example for valueListURN.) 2 - It uses full element names (including the angle brackets) in the Annotation elements which renders it as an *invalid* schema (tested with XML Spy and Oxygen). 3 - It does not define attributes that are mandatory (eg for circle and polygon). 4 - Does not support a single top level parent element which means that having a valid EDXLdistribution is not possible. 5 - valueListURN and value elements can occur in semantically incorrect sequences. Minor: 1 - It references Schemas to import that are not required. 2 - It is extremely verbose as it repeats all the documentation from the specification in the annotation elements (double maintenance effort required) and difficult to read. 3 - Should define the targetNamespace as the default namespace. I am happy to propose an updated XML Schema that addresses the above is the TC feels this is appropriate. Cheers... Renato Iannella National ICT Australia (NICTA) ------------------------------------------------------------------------ -- This email and any attachments may be confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]