[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
---------------------------------------------------------------------
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
IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE:
http://www.ieminc.com/e_mail_confidentiality_notice.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]