RE: [emergency] EDXL DE - XML Schema Issue

[Rex Brooks <rexb@starbourne.com>]

I've looked over the list below, and I didn't find any show stoppers, 
since a couple of the major items are still largely stylistic 
differences in composing the XSD, which I would suggest tend to creep 
into this work every time the initial work is done by an individual, 
which tends to make us automatically write schema that define 
elements locally and and lack a root element because, when we start 
out, we just want to get a starting point that validates locally so 
we can keep on writing. I dread bringing this up, since I went 
through the Requirements Document Template effort, but I think we 
need to develop one or two Specification Schema Templates as well as 
DOMs and Data Dictionaries that are automatically linked and 
generated as we develop them--as starting points from now on, such 
that we start with a root element, define our elements globally, and 
define our attributes, when we think we absolutely must dip into that 
pit of vipers, as attributeGroups, etc. Of course, that's just that 
way I do it, and I really don't want to volunteer for this at this 
time since I am recovering from an illness and I already have my 
plate full again.

However, as long as I am not attempting to do this for the EDXL_DE, I 
can put it on my plate as another task that I will get to, perhaps in 
time for the EDXL_RM, though I wouldn't want to be on the hook for 
that yet.

Ciao,
Rex

At 8:59 AM -0600 11/9/05, Aymond, Patti wrote:
>After our meeting Monday, I thought of why we didn't have incidentID 
>in the DE - because it may contain payloads related to different 
>incidents. That's why we moved incidentID to the keyword field.
>
>The question in my mind is - is it good enough to be an initial 
>standard? We can certainly iron out minor issues in EDXL-DE 1.1, as 
>long as there are no show-stopping issues unaddressed.
>
>I have voted yes to both, but I could be persuaded to change them, 
>if I become convinced that there are any show-stopping issues.
>
>Patti
>
>
>From: Ham, Gary A [mailto:hamg@BATTELLE.ORG]
>Sent: Wed 11/9/2005 7:49 AM
>To: Emergency_Mgt_TC TC
>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>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>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups..php
>
>
>---------------------------------------------------------------------
>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>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups..php
>
>IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
><http://www.ieminc.com/e_mail_confidentiality_notice.html>http://www.ieminc.com/e_mail_confidentiality_notice.html


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309