[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: [ubl] Discussion XSD implementation of extensions
Hi Ken, The model will be non-deterministic if xsd:any ##any namespace is allowed after an element that has a cardinality other than exactly 1. Me and Allan were talking and we think it should be either: 1. move ExtensionReasonCode to be before the any, give it a cardinality of exactly 1. This works in Allan's xmlspy, haven't tested other places, but at any rate at this point it is a deterministic model. 2. Put the xsd:any inside of an element xsd:ExtensionContent. This is preferable to me for working with XSD, but otherwise I find it aesthetically unsatisfying. Also I personally think there are some of these elements that should have a minOccurs of 1, for example the actual content of an extension, but Allan said you have some problems with that due to Sax processing? Cheers, Bryan -----Oprindelig meddelelse----- Fra: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] Sendt: 13. juli 2006 07:49 Til: ubl@lists.oasis-open.org Emne: [ubl] Discussion XSD implementation of extensions At 2006-07-12 13:25 -0700, jon.bosak@sun.com wrote: >MINUTES OF ATLANTIC UBL TC MEETING >15:00 - 17:00 UTC WEDNESDAY 12 JULY 2006 >... > Issue: Multiple extensions > > AGREED that (modulo syntax) one UBL instance may contain > multiple extension constructs, each with its own set of > metadata. > > We discussed GKH's proposed syntax: > > http://lists.oasis-open.org/archives/ubl/200607/msg00053.html > > AGREED that we will attempt to meet the schedule proposed in > this week's Pacific TC call as follows, the objective being > to submit PRD2 for approval as a Committee Draft next week: > > - GEFEG creates new schemas incorporating the NDR decisions > noted above but not the extension element > > - GKH and BR discuss the proposed extension syntax (see URL > above) via email with the objective of creating an > appropriate schema fragment by Friday I haven't seen any new schemas since our meeting this morning, so I did my prototyping with the January schemas. When we get a new set of schemas I can retrofit these tested changes into them and then recreate this test environment with new changes and upload the new tests. But these prove the concepts. I haven't filled in the documentation, and I would ask that someone take the time to fill in the documentation as makes sense ... Bryan, perhaps you can recall some of the descriptive aspects of Stephen's expected use of these elements and fill in appropriate words. I have uploaded a ZIP with a self-contained working environment ... here is the information HTML page: http://www.oasis-open.org/committees/document.php?document_id=19131 The following files are just support files for the Xerces: test\CatalogManager.properties test\resolver.jar test\w3cschema.bat test\xercesImpl.jar test\xjparse.jar The following is the common XSD directory with no changes to any files but one file added, the extension file: xsd\common\CCTS_CCT_SchemaModule-2.xsd xsd\common\CodeList_CurrencyCode_ISO_7_04.xsd xsd\common\CodeList_LanguageCode_ISO_7_04.xsd xsd\common\CodeList_MIMEMediaTypeCode_IANA_7_04.xsd xsd\common\CodeList_UnitCode_UNECE_7_04.xsd xsd\common\UBL-CommonAggregateComponents-2.xsd xsd\common\UBL-CommonBasicComponents-2.xsd xsd\common\UBL-CommonExtensionComponents-2.xsd xsd\common\UBL-CoreComponentParameters-2.xsd xsd\common\UBL-SpecializedDatatypes-2.xsd xsd\common\UnqualifiedDataTypeSchemaModule-2.xsd The following is the maindoc XSD directory with the original January invoice model and my suggested modifications to the model: xsd\maindoc\UBL-Invoice-2-orig.xsd xsd\maindoc\UBL-Invoice-2.xsd Here are the tests: test\invoice-samp.xml - no extensions and no errors test\invoice-samp-bad1.xml - no extensions and an error test\invoice-ext.xml - extensions and no errors test\invoice-ext-bad1.xml - extensions and error (swapped elements) test\invoice-ext-bad2.xml - extensions and error (two top elements in ns) test\invoice-ext-bad3.xml - extensions and error (empty container) Here is the invocation file that tests the above: test\test.bat To view what I see on my screen as the validation results, look at this file: test\test.txt Regarding the empty container bad test: the serial processing problem I discussed in the call is related to the removal of namespace-qualified elements. Now that we have encapsulation of extensions, we can require that the "UBLExtensions" element have at least one "UBLExtension" child because that child element itself is not in a non-UBL namespace. However, if the extension has no metadata and the namespace-qualified child is removed, then the "UBLExtension" child will itself end up empty, which is not an error. We might consider making *something* in the metadata for an extension mandatory, but I'm not sure what ... I'm worried about mandating anything about extensions. Then again, we are mandating UBL stuff about non-UBL extensions, so maybe it is okay to mandate that the writer of an extension include something, say, reason text or some other element (but then they may just leave that element empty). Here is a "diff" of the original Invoice and the modified Invoice to see how few changes were actually added to the document model. Jon, this is the nature of what would be added to each of the 31 maindoc document models: T:\ubl\xsd\maindoc>diff UBL-Invoice-2.xsd UBL-Invoice-2-orig.xsd 13d12 < xmlns:ext="urn:oasis:names:draft:ubl:schema:xsd:CommonExtensionComponents-2" 23d21 < <xsd:import namespace="urn:oasis:names:draft:ubl:schema:xsd:CommonExtensionComponents-2" schemaLocation="../common/UBL-CommonExtensionComponents-2.xsd"/> 46,52d43 < <xsd:element ref="ext:UBLExtensions" minOccurs="0" maxOccurs="1"> < <xsd:annotation> < <xsd:documentation> < ... < </xsd:documentation> < </xsd:annotation> < </xsd:element> T:\ubl\xsd\maindoc> Unfortunately a family obligation keeps me away from my desk on Thursday morning until after lunch time locally ... but the above should satisfy all testing of the schema mechanisms. I need the assistance of other UBL TC members on this because I have to finish some last-minute code list details for Jon and I was not anticipating having to take time to work on XSD stuff at this late stage of the week. And, it turns out that I'm working late on this because of other business obligations I had to finish today, so I may have missed something obvious because of the late hour. I have only tested the above with Xerces. I'm finding that Sylvia is finding problems with my code list work when she uses XML Spy, while errors are not being reported by Xerces, so my work above on extensions needs to be tested by others using other tools. I look forward to any feedback and suggestions for improvements on the above. Thanks again Bryan for bringing up these important issues regarding meta data for extensions. Thanks folks for your help! . . . . . . . . . Ken -- Registration open for UBL training: Montréal, Canada 2006-08-07 Also for XSL-FO/XSLT training: Minneapolis, MN 2006-07-31/08-04 Also for UBL/XML/XSLT/XSL-FO training: Varo,Denmark 06-09-25/10-06 World-wide corporate, govt. & user group UBL, XSL, & XML training. G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal --------------------------------------------------------------------- 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]