Tim,
I
read, that UBL has different structures as you can see from the screen
dumps, except there is an academic level.
Second, I added an example (see thze word file) with
CCTS extension of a BIE Party for the Seller, where the name is SellerNew_
Party. Details. This is to show how an extension mechanism could work,
especially if there was a CC layer.
In
case, CCTS is a modeling methodology, people will ask how to reuse objects.
Example: There are 15 typical contacts, which I want to use in many different
places. Thus I want to define them just once and reuse it. The HOW to do this
belongs to a 'rule set' (maybe called ontology? I do not know) and shall be a
guidance for users, how to customize the models. The criteria (and no redundancy
is one of them) need to be defined, when a BBIE goes into the 'core' level,
e.g. Party. Details, and when it goes into a 'Seller_ Party. Details' and when
it is a customization issue, where the user will do it.
The
same with Account Identifier. UBL implements redundancy in the standard by
defining Buyer Assigned_ Account. Identifier and Seller Assigned_ Account.
Identifier as independent BBIE both for seller and buyer. This will be even more
difficult, if the same approach applies for coded stuff with restrictions on a
DataType code list.
Michael
i
must be missing something but you seem to imply that UBL has separate
structures for Party, Buyer Party and Seller Party. It does
not.
i assume you agree that sometimes a role played a party requires
it have supplementary information known about it. and that at the application
level someone, somewhere is going to have to recognize that a Buyer Party
isn't the same as a Seller Party. so whatever we do needs to identify
these differences, the only point at issue is how we do that.
i only
know of three ways of designing this: 1. have three seperate structures
that happen to have components of the same name and no re-use of any
structures, 2. have one structure encompassing all components for any role
a party may play, then making each role a subset of that structure, (called
subtractive refinement) 3. have one structure encompassing all common
components for any role a party may play, then making each role an extension
of that structure (called core plus contextualization)
EDI standards
tended to follow the second option, UBL follows the third.
Sylvia Webb wrote:
Tim,
Please provide a list of the commercially
available ERP packages in the low and mid range that support your
design recommendations for Parties, Buyer, and Seller without customization.
UBL implementers world wide will need this information.
Regardless of any of our preferences or wishes, all
of the widely available or popular ERP and accounting products
that I see, design software to support a finite set of structures for
each function that they decide to support, including, those specified by
standards like UBL. They look at the similarities for all customer
requirements and select those structures that allow maximum reuse with a
minimum amount of programming. The most robust software products
permit users to customize structures. These also tend to be the most
expensive products available serving the smallest number of
implementers. Even companies that have customizable software are
challenged with which custom enhancements have the highest priority.
With the large number of software products that do
not support the flexibility that we're requiring for the procurement
documents, the growing trend for companies to use commercially available
software instead of doing in-house development, I'm afraid that the
Universal Business Language has good potential to become the Exclusive
Business Language with similar cost barriers to implement that EDI has
today.
Regards,
Sylvia
I guess we agree to
disagree. But if you want some background to re-use of patterns then
you might find Martin Fowler's article listed below of interest.
http://martinfowler.com/apsupp/roles.pdf
Michael
Dill wrote:
Tim,
I hope that you will be able to explain the opinion to the real
world, that there is one party structure in UBL only! I assume that the
real world considers most of the role extensions as part of the party.
details. But let's see, what will happen.
btw: the more I look at the library(ies), the more I feel, it will
be at least extremely difficult to maintain, understand and reuse
this.
regards
Michael
my point to michael was that
UBL 1.0 does not have "multiple structures for party" - we have only one
structure for party. when a party plays the role of Seller we have
additional properties. But that is not a new definition for party.
It is an extension of the existing definition. it seems a
logical way to do extensions but i am happy to see an alternative
proposal.
or, are you suggesting that we can only restrict
structures (such as ABIEs) and not extend them?
Sylvia Webb
wrote:
Tim, you
said "the
backward compatibility is only broken at a syntactic level (except in
one case of Allowance Charge. CurrencyCode). we are desperately
trying to keep 2.0 as semantically compatible with 1.0 as we can.
that means unless we find 1.0 is broken (as in the case
mentioned) we would be very reluctant to change existing
structures."
I did not
notice these multiple structures for party when 1.0 was
developed. My preliminary research shows that mostly
high-end ERP packages support the use of multiple structures for
party. I can name 5 popular ERP software packages in the U.S. for
small to medium size (revenues >$10 million < $100 million)
companies that only support one structure for party. If you need
multiple structures, you must create them yourself, and, they can only
be restrictions of the base party. There are 3 well known
accounting packages for companies with revenues of less than $10
million that include modules for sales and purchasing that do not
support any changes if you need to define or
use multiple structures for party. Buyer and
Seller are universally required for all businesses of all sizes
that are involved in commerce and trade.
I agree we
need to meet the needs of the existing structures defined in 1.0. I
think we also need to find a way to do it that supports the
widest possible user community. The number of 1.0
implementations is low because the standard is in its infancy. Now is
the time to recognize the limitations potential UBL users might
have with multiple party structures and change it when the user
community is small, not after such a change will impact a much
larger user audience because the standard is more
mature.
Regards,
Sylvia
my apologies i thought i had
sent this but it got held up in my drafts folder :-[
just so we dont
lose track of this, I will reference your email and the original
minutes in the minutes of yesterday's call.
Michael Dill
wrote:
Tim,
obviously I was not able to describe clear enough, what my concerns are.
1. Here is the clarification for point b)
Tim minuted, that there are some concerns about the definition. In case, I
said this, then I apologize: I meant the structure mismatch between the
three existing parties. He argued, and I do not agree, that not to change
this is necessary to maintain compatibility. When it became clear that there
will be no minor version 1.1 but a major version 2.0, a number of backward
compatibility was broken anyway. the backward
compatibility is only broken at a syntactic level (except in one case
of Allowance Charge. CurrencyCode). we are desperately trying to
keep 2.0 as semantically compatible with 1.0 as we can. that
means unless we find 1.0 is broken (as in the case mentioned) we would
be very reluctant to change existing structures.
If different from Party. Details, then Seller and Buyer should be qualified
from the generic Party. Details. This would be a semantic CCTS restriction
and technically an extension. It could also be, but this is a different path
and not what I mentioned, a subset mechanism.
sorry, Sue suggested that we should always use
restrictive subsets and I thought you agreed with her. i now
realise your point was different
In cases Seller and Buyer are not different from Party. Details, they should
wherever possible just be defined by an association. Just, if the generic
party is not sufficient a qualified ABIE Seller_ Party. Details should be
allowed to define. Thus a conceptual decision will depend on concrete user
requirements. AND: the necessary decision will become part of a taxonomy how
to describe a number of typical modelling problems.
But, currently, even seller/buyer do not have the same structure.
they do not have the same structure because they
are used for different purposes and required different pieces of
information.
My concern is, that this mismatch will be a reason to have 30-100 different
structures for parties. Second, and please remember later, that IMO neither
big corporates nor ERP vendors nor central EDI departments will be satisfied
with such a solution. They rather need a generic party in the documents.
there is a generic "party" and all re-uses (scuh
as Buyer and Seller) use this common structure. So if
application vendors write a function to deal with UBL Party it will
handle this common structure. In addition when they want to
process a Buyer Party (or a Seller Party) they will need functionality
that deals with the specific requirements of parties in those roles.
I see this a reasonable and logical.
surely it comes down
to the fact that when we have additional requirements for specific
roles we must have the additional information components that support
these requirements. Currently UBL both conceptually supports the
idea of extension - i thought you would appreciate
that.
in our existing models it is not semantic restriction and
physical extension. it is semantic extension and physical
re-use. i see no reason why we should change this.
2. Here the clarification for point 3
The sentence "Michael raised a concern about the decision to adopt ATG2
Unqualified data types meant the modeling of these was outside UBL's
control." is not completely correct. I'm not complaining the decision. I
said, that UBL has to be aware, what it means to use the ATG2 unqualified DT
- for code lists, for further qualification, for code list mechanism - and
that this needs to communicated to users and developers.
Tim argued that with the ATG2 uDT decision, "We now considered our models
stopped at that level." I feel, that in respect of the code list issue and
the qualified DT, this low level is already under discussion.
further apologies, the language could have been better phrased. it should have read...
"Michael raised a concern THAT the decision to adopt ATG2 Unqualified data types meant the modeling of these was outside UBL's control."
and as you may have also realized the question of dealing with qualified/specialized data types is still open and being discussed.
best regards,
Michael
-----Ursprungliche Nachricht-----
Von: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Gesendet: Mittwoch, 31. August 2005 14:36
An: ubl@lists.oasis-open.org
Betreff: [ubl] Minutes for Europe/Asia TC meeting Wednesday 31st August
Attendees:
Mikkel Brun
Sue Probert
Michael Dill
Peter Borresen
Tim McGrath
1. STANDING ITEMS
Additions to the calendar (http://ibiblio.org/bosak/ubl/calendar.htm)
Sue:
TBG 17 will meet October 31 - November 4th in Copenhagen and also February
13 to Febraury 17th 2006 in Washington
ATG2 will meet sometime in January 2006 in Australia TMG will also meet
sometime in January 2006 in Australia
Liaison reports
Noted that the TaxXML position paper was distributed
Subcommittee reports (including the new Procurement and Transportation
SCs)
Procurement SC will try and complete the model loading into EDIFIX this week
(we think we are 1 week behind the schedule) Transportation SC are working
on merging the two models and removing unnecessary structures from the DTTN
model.
Team reports
Catalogue team will report weekly on progress
Review of Asia/Pacific and Atlantic TC minutes No comment
2. CONTENT WORK
* Document Models
status
Peter B has completed and distributed the draft 2.0 extended procurement
models Sylvia is loading them into EDIFIX and will instruct Betty on how to
do maintenance Michael raised some concerns about the content of the
procurement models:
a. how will we deal with "standalone" BBIEs (those not define as re-usable)?
Tim suggested we define these in the Common Basic Component schema but
Michael sought a modelling level solution. Agreed to continue the
discussion offline until we had defined a position for the TC to consider.
b. How can we have multiple definitions for "Party" (eg BuyerParty,
SellerParty and Party)?
This appears to be a question of whether we want to extend ABIEs when we
re-use them (BuyerParty extends Party) or only allow restriction (Party must
contain all BBIEs and BuyerParty is then a restriction). Tim suggested it
was acadmeic for UBL 2.0 as we had to support exist extensions. The
question of whether we should allow only extension, only restriction or both
was unresolved. Sue noted that CEFACT have adopted a "only restriction"
approach to their models.
c. Michael made a point that the GS1 catalogue/pricelist models were worthy
of consideration.
Tim noted that a representative from GS1 had participated in the Copenhagen
workshop and contributed many useful ideas. We had to adapt these to fit in
with UBL 1.0 (and now 2.0) models as well.
schedule
We will try and gain back some slippage in the schema generation stage as
initial tests appear promising.
3. NDR WORK
NDR issues for review in tomorrow's meetings.
* code lists
It was noted that any comments on the new NDR document are due now.
Michael raised a concern about the decision to adopt ATG2 Unqualified data
types meant the modeling of these was outside UBL's control. He felt this
meant that other implementations of CCTS may not be interoperble becaseu UBL
releied on schema level compatibility rather than conceptual level.
Tim suggested that we had delegated low grained models (like Date, Time,
Code, etc..) as data types to CEFACT becasue we hoped every XML
implementation of CCTS would use the same schemas. We now considered our
models stopped at that level.
4. Other items
none
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business
Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E
-22FF8CA5641F&ttype=2&tid=10476
---------------------------------------------------------------------
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
DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.23/99 - Release Date: 12/09/2005
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476
|