[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl] Questions - UBLExtensionType
Tim,
Can you point me to the CCTS datatype that this
ABIE is created from? While the extension content can be xsd:any, imo, the
ABIE needs to conform to our NDR rules.
Regards,
Sylvia
I thought we had agreed that it would be an ABIE, because there is
metadata we want to encourage be used. Peter B. in his email of 20th May (http://lists.oasis-open.org/archives/ubl/200605/msg00107.html)
suggested:From: Tim McGrath [mailto:tmcgrath@portcomm.com.au] Sent: Wednesday, July 05, 2006 7:36 PM To: ubl@lists.oasis-open.org Subject: Re: [ubl] Questions - UBLExtensionType ID [0..1] (ID type) (corrected from the original) Name [0..1] (name type) AgencyID [0..1] (ID type) AgencyName [0..1] (Name type) VersionID [0..1] (ID type) AgencyURI [0..1] (ID type) URI [0..1] (ID type) ExtensionReasonCode [1..1] (Code type) (personally i dont think we can mandate a code list, nor provide one) ExtensionReason [0..1] (text type) ExtensionContentAny [1..1] (xsd: any) So i think the basic component Ken refers to is actually called ExtensionContentAny. i have not seen any dispute on this, so isn't that what we should be doing? i missed the Brussels plenary but i thought this was to be written into the NDR. however it may be simpler just to build it into each document's spreadsheet model. this still leaves the problem of what CCTS datatype is ExtensionContentAny. Sylvia's point is that UN/CEFACT has no datatype in their schemas that uses an xsd:any. we are obliged to use only their datatypes (or restrictions thereof). as xsd:any is the top of the type defeintion hierarachy i dont see how we can create it by restricting something else. What is missing here is a CCTS datatype for "anything". in its absence we may have to create it ourselves. my call would be to do as Ken says and define it as a SimpleType. I also suggest we propose this as a new dataype to the CCTS working group. Given we have no calls this week, can we try to decide on this over email? So i would ask you to consider... a. have i got this right? b. is the structure of "UBLExtension" ABIE as given above correct? c. should the definition of the "UBLExtension" ABIE be in the spreadsheets or hardcoded in the NDR? d. do you agree to the approach of bypassing CEFACT datatypes for ExtenstionContentAny? e. is there another suggestion of how to solve this? Footnote: The nearest thing CCTS has is Binary Object which uses xsd:base64Binary. one suggestion is that we take their unqualified datatype of Binary Object and create our own qualified datatype called "AnyType" that has Binary Object. Format. Text as being the string "xsd:any". i think this achieves what we want to say, that is "within this element you can put whatever you want" but it isn't technically a restriction of a datatype. this still complies with our NDRs CTD6 and CTD20, because it is a semantic restriction not a technical one. but we would have to handcraft the qDT schema for this so that our implementation of "AnyType" uses the syntax we want. Sylvia Webb wrote: Ken, The UBLExtensionType must be based on one of the data types specified in the uDT schema module. We cannot create new data types. This is done in UN/CEFACT. UBL reuses what CEFACT approves. If the UBLExtensionType needs to be a ABIE that is reused in one or more UBL documents, it must be defined in the CAC schema module. If the ExtensionType needs to be a BBIE, it must be defined in the CBC schema module. Regards, Sylvia -----Original Message----- From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] Sent: Tuesday, July 04, 2006 11:03 AM To: ubl@lists.oasis-open.org Subject: Re: [ubl] Questions - UBLExtensionType Here is some input for the NDR team to consider ... I'm not practiced at writing NDRs so I'll offer the following and the NDR team can use it as they wish. The following is an XML instance (modified from January) with an extension in which multiple foreign elements are being used: <?xml version="1.0" encoding="UTF-8"?> <Invoice xmlns="urn:oasis:names:draft:ubl:schema:xsd:Invoice-2" xmlns:cac="urn:oasis:names:draft:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:draft:ubl:schema:xsd:CommonBasicComponents-2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:draft:ubl:schema:xsd:Invoice-2 UBL-Invoice-2.xsd"> <cbc:UBLExtension> <x:this xmlns:x="urn:x-this"/> <y:that xmlns:y="urn:y-that"/> </cbc:UBLExtension> <cbc:ID ... I've suggested making this a basic component rather than an aggregate component since this is the lowest point defined by UBL. Seeing, however, that other declarations in the CBC module are all simple types, you may wish to move this to the CAC module. But in my experiments I put it in CBC. I'm assuming that since no existing data types are extensions that we would need a new data type called "Extension" and a new representation term named "Extension" so that the DEN for the extension element in the Invoice model would be: Invoice. UBLExtension. Extension I'm also assuming the data type would be "Extension. Type" but I'm not sure if this requires an extra declaration or not. So, I added the reference to the extension into the Invoice module as can be seen in this fragment: <xsd:complexType name="InvoiceType"> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:ComponentType>ABIE</ccts:ComponentType> <ccts:DictionaryEntryName>Invoice. Details</ccts:DictionaryEntryName> <ccts:Version></ccts:Version> <ccts:Definition>The document used to request payment</ccts:Definition> <ccts:ObjectClass>Invoice</ccts:ObjectClass> </ccts:Component> </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element ref="cbc:UBLExtension" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation> <ccts:Component> <ccts:ComponentType>BBIE</ccts:ComponentType> <ccts:DictionaryEntryName>Invoice. UBLExtension. Extension</ccts:DictionaryEntryName> <ccts:Definition>The extension point for an arbitrary amount of foreign content not defined by the UBL models.</ccts:Definition> <ccts:Cardinality>0..n</ccts:Cardinality> <ccts:ObjectClass>Invoice</ccts:ObjectClass> <ccts:PropertyTerm>UBLExtension</ccts:PropertyTerm> <ccts:RepresentationTerm>Extension</ccts:RepresentationTerm> <ccts:DataType>Extension. Type</ccts:DataType> </ccts:Component> </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="cbc:ID" minOccurs="1" maxOccurs="1"> ... I added the following two declarations to the CBC module: <xsd:element name="UBLExtension" type="UBLExtensionType"/> ... <xsd:complexType name="UBLExtensionType"> <xsd:sequence> <xsd:any namespace="##any" processContents="skip" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> And xjparse with Xerces was able to parse my instance without any errors. Finally, I've suggested that the extension point be the very first child of the document element. This allows a processing application to encounter all extensions before hitting any standardized content. By caching and interpreting the presence of extensions, the standardized content can then be processed with the complete information at hand. If the extension content followed any of the standardized document content, then an application may have to postpone the processing of the standardized content until the presence and content of a possible extension is determined. By having the extension first, then the absence of the extension is determined immediately and the standardized content can be processed as desired. SAX-based and other stream-based applications process the content serially, thus supporting this suggestion rather than relying on random access as available in XPath or DOM. I hope this is helpful. Perhaps others can do some tests using other processors. Thanks! . . . . . . . . . . Ken At 2006-07-03 07:06 -0700, Sylvia Webb wrote:Dear NDR Team, We have some additional questions about the UBLExtensionType. These topics were discussed in email but no final decisions were included in the 28 June NDR draft. 1. How does "UBLExtensionType" look like? Maybe this like: <xsd:complexType name="UBLExtensionType"> <xsd:sequence> <xsd:any processContents="skip"/> <!--Are there any restrictions for attribute "namespace"?--> </xsd:sequence> </xsd:complexType> 2. What schema "UBLExtensionType" and global element "UBLExtension" should be declared in? 3. Where is element UBLExtension used? 4. Are there any documentation rules for the UBLExtensionType? Thanks. Regards, Sylvia-- 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 --------------------------------------------------------------------- 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 -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160 web: http://www.portcomm.com.au/tmcgrath |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]