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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: Re: [ubl-lcsc] AW: UBL 1.0 Beta - Data type issues


I am a bit unsure what you mean by some of your questions but I will try and explain what I think you are asking.

Firstly, to be clear about this - the spreadsheet models from UBL are not normative and never have been.  the only normative expression of the UBL model is the XSD schemas.  these are the UBL document models expressed in XML syntax.

i don't see why it is significant that we can create two different views of the model or that the CCTS data types/representations can be implemented in various ways.

one of our objectives with the CCTS components of the UBL schemas (the CC Type, Data Type and Rep.Term schemas) was to mkae these algin with work of OAGIS and oterh XML vocabulary builders.  This gives us a lowest common denominator level of alignment.  If we accept this objective, we cannot (and should not) model and build these ourselves.  I, for one, would prefer ATG2/TBG17 (or whoever is responsible with CEFACT) to simple provide these.  In the same way that W3C provide the XSD data type, CEFACT should provide the CCTS data types(meaning CC Type and Rep Term schemas)-  extending the XSD ones. UBL can then provide it own extensions (as Data Types).  to me, it makes sense to have xsd:datatype, refined as ccts:datatype and this refined as ubl:datatype.

Having said that, i sympathize with your view that UBL should decide on its own how to do this and make the same architecture we use for BIEs work for data types as well.  afterall, there is no conceptual difference between UBL defining an ABIE called Measurement and the CCTS Measure structure.  All these things (Codes, Identifiers, Dates, Amounts, etc.) can be described as ABIEs.  This is the point i made about why UBL would not want its own data types - we should model these as ABIEs.

That is why you can have many different models - it depends what objective you have.  Alignment with other XML vocabularies or a consistent modeling architecture.  

I agree we need a clear UBL vision for this issue. But we are struggling with this because we have had a few false starts and the CEFACT vision is still being formed.

With respect to code lists.  I am now beginning to realize that we have not been viewing these the right way.  Most of what we discuss as code sets is not really about codes at all.  We are talking about constrained sets of values for a given BBIE.  This has nothing to do with them being 'codes' - that is, they are not necessarily abbreviations for something else (which is our definition of a code).  This is significant because it means sometimes we are talking about populating enumerated lists and at other times just identifying sets of values that are defined elsewhere.  From a modeling point of view we should be capturing the meta data that tells us what these sets of values are or where to find them.  The code list catalog sheet attempts to do this and until we get a UBL mechanism for implementing these, we cannot do any more.

PS i am still awaiting my access key for the UBL Reader.


Michael Dill wrote:
		Dear all,

		A few weeks ago, Anne sent an email to an UBL list which
gave a download link where the UBL 1.0 Beta version can be viewed as a set
of UML data models or as a set of schema objects. A copy of this email is
attached below. I'd like to distribute the free UBL 1.0 Reader in January,
because of I think it  makes the UBL models and schemas easier
understandable for users. But I'd prefer to get any echo from the experts
whether the data whether are OK or not. 

		These views illustrate well the importance of the systematic
CCTS naming of the objects inherited consistently within the data models
and across the schemas. 

		In addition these views also illustrate a significant
potential problem: a modeller (in this case me!) can very freely decide on
what modelling rules to apply. 
		Example 1: I decided to build two views of the same models:
a CoreComponentView and a UBL object name view.
		Example 2: I built one model object Datatype for each
different entry in the Data Type/Representation Term column of the UBL
spreadsheets and restricted the used CoreComponentTypes just once. But is
would be also possible to refer to the CoreComponentTypes directly and not
to restrict them. Result: two different data models.

		This raises the following questions for me:
		a) is it OK, that UBL data models, which are not expressed
in a spreadsheet, can adopt different modelling approaches?
		b) does the UBL TC feel, my UBL representation is OK?
		c) If not: how should the UML representation of UBL data
look?

		Currently, the normative spreadsheets for the documents and
the reusable type structures are the only official instantiation of the
UBL data model available. These spreadsheets contain no direct links or
explanation on how to handle data types and codelists at the data model
level. The models are actually incomplete and consequently there is no way
to derive UBL schemas directly and automatically from the spreadsheets
alone, i.e. neither a logical way nor a technical way. 

		It can probably be assumed that some future UBL users will
want to develop/evolve their specific requirements from the UBL data
models and then they will probably be asking similar questions. 

		I think that it is very important to be very clear whether
it is the schemas or the data models which are the master from which
extensions and customisations should be developed. If the schemas are
considered to be both the maintenance and publication master data, then
the spreadsheets should become just a derivative of the schemas and their
position in any explanatory diagrams should be changed accordingly (i.e.
to mark them clearly as XSD derived). If not, then I suggest that the UBL
NDRs should be used and extended, if necessary, to rule how to go from
model to schema. This latter approach would require that all necessary
data including data types, codelists and their relationships must be
stored in the data models.

		To which TC(s) shall I address these issues?

		thanks
		Michael Dill


	Hi Michael,

	I apologize that I am not as quick as you'd like in getting
	your information to the team, but we usually only meet once a week,
	so it usually takes a few days to get back to people on things.
	I just sent your information to the TTSC (and added you to the
alias).
	We are in the process of developing a requiements/scope document,
	which I have attached, and you may feel free to add your comments
	as well to the list.  This was sent out last week.  I am putting
	your tool on the agenda for next week, but some may reply earlier
	as I sent them your email showing interest in feedback.

	In terms of ccts, both Garret and Gunther have been closely working
	with us to ensure CCTS compliance.    As you heard, I'm sure, we
have a
	bit of a problem with CCTS changing.  But for the Beta release we
believe
	we achieved CCTS 2.0 compliance.  I think that may be stated in the
	documents somewhere.  I'll see if I can find where.

	Now, since the release Sue Probert has told us that there are a few
more
	changes to CCTS.  But she said they were small and we hope they will
	be done in time for us to put them into the final release.  This
means they
	will have to be done before the end of December.  So if you can help
	in this regard, please do!  :)  We are doing everything we can to
remain
	in compliance!

	I'm not sure what you mean when you say " + re-use of reusables ".
	I believe reusables are CCTS compliant as well.  They are part of
the
	UBL data model.  Perhaps I misunderstand this part of the question.

	-Anne

	dill wrote:


	>-----Ursprüngliche Nachricht-----
	>Von: dill [mailto:dill@gefeg.com]
	>Gesendet: Montag, 1. Dezember 2003 22:03
	>An: anne.hendry@sun.com
	>Betreff: UBL Reader
	>
	>
	>Anne,
	>please find enclosed the download for the UBL reader. If you feel,
it's OK,
	>then I'd be glad to get any feedback.
	>I think, it helps really for the further UBL development. For
member of the
	>TC the UBL Reader and Editor is free, for the direct Standard work.
	>Thank you
	>Michael Dill
	>
	>Dear All,
	>
	>GEFEG has built a version of its EDIFIX schema and data model
reader for the
	>Universal Business Language (UBL). The GEFEG UBL Reader offers an
easy
	>access to the UBL schemas and data models through its unique
combination of
	>tree structures, easy navigation and clearly arranged background
	>information.
	>This UBL Reader containing both the UBL 1.0 Beta data models and
schemas is
	>available as afree of charge download from the GEFEG.COM web-site.
	>
	>The link for downloading the UBL Reader is:
	>http://www.gefeg.com/en/edifix/reader-ubl.html
	>!!! Please do not forget to choose the 'UBL Reader' from the choice
of
	>reader list box !!!
	>
	>Choose to download the self-extracting .exe and then run this to
unzip and
	>automatically install the reader software.
	>
	>During installation you will be asked for licence information.
Please copy
	>and paste the following details into the requested fields:
	>
	>Name: UBL Reader - Free Of Charge
	>Licence: FX-271103-20003-1620
	>Key: H1K16-R1111-KN1BL-ZF
	>
	>As UBL is UN/CEFACT Core Component compliant, the GEFEG UBL Reader
offers
	>TWO Views of the data models! One set of UBL data models presents
the object
	>names as UN/CEFACT Core Component Directory Entry Names whilst the
other
	>presents the UBL object names.
	>
	>Both sets of data models as well as the set of schemas demonstrate
the
	>inheritance of the Directory Entry Names and other documentation
remarks.
	>This inbuilt inheritance avoids rekeying and thereby provides a
redundancy
	>free environment.
	>
	>If you have any interest in having a free GEFEG EDIFIX UBL Editor
to assist
	>with the standardisation work of the OASIS UBL TC including
spreadsheet
	>export and import of the models, automatic schema derivation from
the
	>document models etc., then please send me an email.
	>
	>Please have a look at the data models. I'd be glad if there were
any
	>comments about them which could help to improve the data.
	>
	>We hope that you enjoy these views of all the hard work of the past
two
	>years.
	>
	>Best Regards,
	>Michael Dill
	>
	>
	>
	>Further Features of the UBL Reader
	>==========================
	>Provision of clear hierarchical tree structures, enriched with
comments and
	>descriptions Availability of all information relating to an element
directly
	>in the tree at the element position Opening and closing of
sub-trees Ms
	>explorer-like backward and forward navigation Viewing of a
structure diagram
	>for a message, or parts of a message Viewing of a collapsible and
expandable
	>UML class diagram of a data model, or parts of a model
	>
	>
	>Notes for EDIFIX users:
	>=======================
	>If you have already any version of EDIFIX installed on your
computer, then,
	>please:
	>
	>1. make sure that all EF sessions are closed during installation of
the UBL
	>reader 2. choose a directory other than the normal EDIFIX directory
to store
	>the UBL reader program files (During installation EDIFIX will ask
you where
	>you wish to store these program files) 3. choose a directory other
than the
	>normal EDIFIX directory to store the UBL reader data files (During
	>installation EDIFIX will ask you where you wish to store these data
files
	>
	>  
	>
    

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php.

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160



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