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] EDXL DE - XML Schema Issue


Re: schema validation

It is now a requirement in the OASIS TC Process Policy that all schemas/xml instances be valid. I typically rely on the TC to
confirm this and do no further testing. The final documents must be published by tomorrow in order for the TC members to have
sufficient time to review them before casting their final votes. 

I would like to recommend to the TC that you strongly reconsider this submission - the comments I have seen give the impression that
we are trying to follow someone else's timeline, and not conduct the due diligence necessary to provide a quality specification. The
goal should not be to "get something out there" that can be retrofitted later, as in the case of CAP, but instead to provide a
quality specification that can be built upon.

Regards,

Mary

---------------------------------------------------
Mary P McRae
OASIS 
Manager of TC Administration
email: mary.mcrae@oasis-open.org  
web: www.oasis-open.org 
phone: 603.232.9090
cell: 603.557.7985
  

> -----Original Message-----
> From: Sylvia Webb [mailto:swebb@gefeg.com] 
> Sent: Wednesday, November 09, 2005 8:10 PM
> To: 'Rex Brooks'; 'Renato Iannella'; 'Emergency_Mgt_TC TC'
> Subject: RE: [emergency] EDXL DE - XML Schema Issue
> 
> I'm sorry I didn't respond earlier, I've had all day meetings.
> 
> It's my understanding that the revisions needed to be 
> completed literally this past Monday and no later than this 
> coming Monday.
> 
> The documentation was verbose because that is the 
> recommendation for XML standards from ISO and UN/CEFACT. UBL 
> uses these guidelines as well. It is unusual that the 
> documentation is exactly the same as the spec, however, I 
> believe this was a result of a lack of time.
> 
> WRT errors from Spy and Oxygen, as a software vendor of XML 
> products, one of the things we have learned is that this is 
> not unusual. The schema did validate with Xerces and I 
> believe MVS. NIST has a free online website for testing 
> schema using 3 validates.  As a TC, we need to determine how 
> much QA we want to do, and, how we want to proceed if we find 
> that well known IDE's use a different or relaxed 
> interpretation of the W3C spec that causes
> problems.   
> 
> If Renato sends me his suggestions, I will do my best to 
> incorporate them.  
> 
> I think the TC needs to decide if they want to move forward 
> or delay one more month to allow us to do one more QA.
> 
> Regards,
> Sylvia
> 
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Wednesday, November 09, 2005 7:32 AM
> To: Renato Iannella; Emergency_Mgt_TC TC
> Subject: Re: [emergency] EDXL DE - XML Schema Issue
> 
> I would like to suggest that once Elysa establishes what our 
> timeline requires, that Renato work with Sylvia and Dave, if 
> these three individuals can spare the cycles to get the 
> schema massaged into correct form as needed.
> 
> Ciao,
> Rex
> 
> At 2:02 PM +1000 11/9/05, Renato Iannella wrote:
> >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_workg
> roups.php
> 
> 
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.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_workgr
> oups.php 
> 



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