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] Further SGTG explorations - some new revelations


OK. Sorry for being obtuse - having to catch
up a lot.

>>>>> ... but it seems incomplete in that it
>>>>> doesn't have Name Type and Graphic
>>>>> Type (perhaps others).


Back then it was advised that we should just
copy the CCT schema and edit it to create the
UDT schema. It is not strictly necessary to
actually use XML Schema derivation / import.
We created the first UDT schema this way.
The UDTs which don't have corresponding CCTs
by an exact match should be copied from the
CCT which CCTS says to use as the basis.
E.g. the proper way to create a UDT Name
Type is (if I remember correctly) to look up the
Name type in the CCTS and see that, say, it
is 'derived' (in model sense, not in XML Schema
sense) from the CCT Text Type and so you can
just copy the CCT Text Type and make a few
edits to create a UDT Name Type. At least that
was accpetable for UBL 1.0. No need to actually
import the CCT Text Type into the UDT schema
and extend it to produce a UDT Name Type.

Likewise the CCTS will tell you that the Graphic
UDT is derived from or based on a certain CCT
- presumably the BinaryObjectType. Same goes
for others like PictureType. If you look at Picture
type in the CEFACT unqualified datatype schema
(2p0) it has documentation saying

<ccts:PrimitiveType>binary</ccts:PrimitiveType>

which indicates that it it has its roots in the CCT
binary object type.

Best regards

Steve
---
Stephen D Green




2009/12/20 G. Ken Holman <gkholman@cranesoftwrights.com>:
> At 2009-12-20 15:36 +0000, Stephen Green wrote:
>>
>> Going back to the original reasons for including
>> the Core Components Types as a schema in UBL 1.0,
>> we did so for information reference only since no
>> other schema 'uses' it. It is a bit like an abstract
>> concept schema and the only connection of other
>> artefacts to it is conceptual.
>
> I understand that was its original purpose, yes.
>
>> The unqualified
>> datatypes depend on these core component types
>> in the model, not in the schema package.
>
> Agreed, but the unqualified data types chosen by UN/CEFACT do not include
> the supplementary components we need for some types, and they hard wire the
> code list stuff we don't need.
>
>> The
>> unqualified datatypes have no schema reference to
>> the core component types but their *design* stems from
>> the core component types.
>
> Yes, I understand that.  But is it "wrong" to find a home for the core
> component type schema fragment in the schema hierarchy?  My plan was to
> explore creating the UBL UDT by importing the CCT schema, thus inheriting
> all of the supplementary components and having none of the decisions made by
> UN/CEFACT in their UDT.
>
>> It is the qualified datatypes
>> which have the UBL-specific details such as code lists
>> choices determined by the modelers.
>
> Right in UBL 2.0 but it has been proposed (and accepted) that in UBL 2.1
> UBL-specific details such as code list choices determined by the modelers
> will be expressed in a CVA file for use in the second pass value-validation
> of instances.
>
>> The UBL business
>> model architects should have no influence at all on
>> the core component types or the unqualified datatypes
>
> Agreed.  Totally.
>
> My question stemmed from the current SGTG proposal where I derive a
> code-list-free version of the UN/CEFACT UDT and then augment that in the UBL
> UDT to bring in the supplementary components we need that UN/CEFACT chose
> not to expose:
>
>  http://www.oasis-open.org/committees/document.php?document_id=34338
>
> It is proposed for UBL 2.1 that all business objects are based on the UBL
> UDT, not on the UBL 2.0 UN/CEFACT UDT.
>
> When I get the time to look at it, I will try to create that very UBL UDT to
> simply import the UN/CEFACT CCT to get the supplementary components we need
> without any of the current UN/CEFACT decisions of hardwired code lists.
>
> It has already been proven that UBL 2.1 cannot use the UBL 2.0 UN/CEFACT UDT
> because of validating instance-level metadata and creating the union of
> out-of-date code lists and up-to-date code lists.
>
>> but only on the qualified datatypes (such as codelist
>> bound qualified code types). So it still seems confusing
>> to even include the CCT schema in the package (though
>> I don't recollect if the NDR says to do so).
>
> Hopefully I've clarified where I will be looking when I get around to do
> this.  I'm delayed with some (welcome) revenue work that is occupying my
> time.
>
> With Roberto's help in finding the latest CCT, I'll see if I can pull it
> together and I'll publish an updated SGTG.
>
> BTW, since all of the business objects are already based on the UBL UDT in
> the draft SGTG for 2.1, this work will be irrelevant to Fulya's work on
> generating the aggregate and basic schema fragments.  This is lower level.
>  I'm just trying to find the way to do it without having to derive something
> from the UN/CEFACT UDT fragment.
>
> . . . . . . . . . Ken
>
>
> --
> UBL and Code List training:      Copenhagen, Denmark 2010-02-08/10
> XSLT/XQuery/XPath training after http://XMLPrague.cz 2010-03-15/19
> XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
> Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
> Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
> Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Male Cancer Awareness Nov'07  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.  Follow this link to 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]