[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ubl-ndrsc] RE: [ubl-lcsc] Newest version of the OO-design position paper.
Well, I
can only agree! Stig Korsgaard M.Sc.E., Standardisation Coordinator Danish Bankers Association Tel: +45 33 70 10 83 Cell: +45 21 21 82 34 Fax: +45 33 93 02 60 E-mail: stk@finansraadet.dk -----Original
Message----- Gunther, You wrote - But all
(and really all) XML instances will be processed by applications and tools only.
Only the designers, developers and support peoples are reading less XML
instances partially. Therefore, we have to think about which kind of
"containers" and "groups" are necessary and efficient for
applications (not for humans). I don't
think this fits with what we have identified as our core principles. To wit - ·
Legibility - UBL
documents should be human-readable and reasonably clear ·
Simplicity - The
design of UBL must be as simple as possible (but no simpler). Mark Hello
Joe, I do not
know, why we need this high-level containers like "Header, Summary, Party
etc.". This is a separation for humans, because all layouts of the hard
copies of business documents are divided in this strucute. Kind
regards,
Gunther -----Original
Message----- Hello, Regarding CCTS
compliance: I don't recall anywhere in the CCTS v1.8 spec that mandates
the structure of XML documents in regard to Dictionary Entry Names (I could have
missed that detail, though). I believe that these are 2 separate and
distinct concepts. In any event,
I don't believe the paper made a strong enough case for doing away with
"good" (in my opinion) structure principles (the container
approach, as we call it). Plus, I think it makes great sense to divide
such documents into high-level containers such as Header, Detail (or LineItem),
and Summary, I believe the arguments in the paper were weighted much too
heavily on tools and performance - and while always a valid concern, I don't
believe that in this day and age either should be a concern to this regard
(that is, what "harm" will a few additional containership tags do for
performance). I would personally like to see a much stronger case made
for the proposed approach. Thanks for
listening. Joe ************************************************************************** -----Original
Message----- Hello Arofan, XML is not a hype anymore. One of that reason is the complexity of
the business documents. The most of the business documents have too much
hierarchies. More than EDIFACT or ANSI ASC X.12 ever have. These many
hierarchies makes the business documents very heavy or not at all processable.
I know some projects, which had some big problems with the many hierarchies. - It was not possible to put this documents or part of these
documents into the databases - It was a big effort to realize any application interface for
processing these documents - Additionally, the effort to define a XSLT rule was much more
higher as for defining any mapping rules for EDIFACT and Inhouse formats. I guess that the instances itself do not need any containers,
because it is easier to define any interfaces for business objects. My suggestion is that we have partial object classes instead of
unstructured containers. This partial object classes makes the building of
structure much more controllable and the partial object classes are reausable,
too. Otherwise, if we use "containers", than we need some
simple rules for the definition and processing in a automatic manner. One
another import thing is, that the names containers impacts the dictionary entry
name. If you use a container with the name "header", than the
dictionary entry name will be "order.header.id" instead of
"order.id". This representation is not ebXML CCTS compliant. Kind regards, Gunther -----Original
Message----- Gunther: I
have a fairly basic question for you. Today,
most business applications do not view XML business documents as a direct
serialization of the objects that they use internally. Rather, the business
document represents a somewhat truncated version of the object hierarchy,
designed for exchange between applications. While I see the value of having a
formal relationship between the model on which the object hierarchy is based,
and on which the business document definitions are based, I have always thought
that the serialization from one to the other was a very useful level of
indirection - different apps may actually want to take the same object
structures and treat them differently, given that they generally perform
different functions. You
approach removes this level of indirection (as well as all the containers,
making it difficult to use for non-object-based systems, a different issue) -
are you sure that this is the best approach? What
I am trying to get at here is the middle ground between a strictly object-based
approach, and one that will be suited for use by other types of applications,
while not losing the merits of what you have outlined. Cheers, Arofan -----Original
Message----- Hello
all, In
this paper all aggregates representing an object. The subelements which are
basic business information entities representing the attributes of an objects. An
the aggregates insided of an objects are further objects or parts of an
objects. The object itself refers to these furhter objects. In
addition all containers are avoided, consciously. Because it is not
possible to represents containers as objects with attributes and influence the
representation of a conclusive class diagram unfavorably. Please
review this document and send me your comments and remarks. Kind
regards,
Gunther |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC