OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: Re: [ubl] Questions - UBLExtensionType


i am unclear on your question.  an ABIE does not have a CCTS datatype.

Sylvia Webb wrote:
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
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

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:

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

-- 
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]