Re: Methodology for describing Core Components(Rev.04)

[Hisanao Sugamata <hsedi@attglobal.net>]

Hi Martin,
I'd like to give you my response to your comments below.

At 12:02 00/07/06 +0100, Martin Bryan wrote:
>Hisanao
>
>Following pilot work undertaken prior to, and at, last week's UK Data 
>Harmonization Group meeting I have been asked to extend the data capture 
>forms to provide more functionality. In the course of doing this I have 
>noted some problems with the basic data model, as follows:
>
>Whilst I have added an Industry field that matches the Industry entry in 
>the EntityApplication box of the latest revision of the model, I note that 
>the revised model does not currently record the fact that both Industry 
>and Business Process are properties that have been addeed to the models 
>for EntityPattern and BusinessEntity. I have also been asked to add 
>Industry to the CodeValue entity as certain code values are only 
>applicable in certain industry segments.

-> Agree. I'll add them in the section 5 of the next revision.


>The forms still contain no Unit of Measure entry. The new Basic Data Type 
>field is the nearest, but it is based on the basic data types of XML 
>Schemas, so I am not completely sure that this is what is meant by this 
>field (which has always confused me). See if you think this is a good 
>match for what you intended, or if this property is no longer relevant to 
>the model.

-> Disagree. When we introduce the class "height", we'd like to know it's 
by "meter" or "feet".  There are bunch of unit of measures defined in 
UN/EDIFACT recommendations.


>Users have complained about the lack of matching of form names with names 
>used in the model. I have tried to use easily understandable names in the 
>forms, so you have  Pattern instead of EntityPattern (or as it is 
>described in section 3, an Analysis Pattern) and Permitted Value instead 
>of CodeValue. Is it really important that we align terminology? Should we 
>maintain a listing of the equivalences? Pattern seems particularly 
>confusing to people: would we be better to use Analysis Pattern in all 
>instances of referring to this object?

-> Agree. I should be careful on the next revision.


>The model for ValueDomain seems to be wrong. At the moment the forms only 
>show Type and Identification (this being a pointer to the identifier of 
>the associated code set or data format). I really feel we need to try to 
>realign the model with the forms better from Representation Class downwards.
>
>My mappings of your Representation Classes to XML Schema built-in 
>datatypes is as follows:
>
>Amount -> Decimal
>Code -> String
>Description -> String
>Identifier -> String
>Name -> String
>Number -> Integer, Decimal and Float (I have not provided support for 
>fload as I do not believe it is relevant for most e-business applications)
>Percent -> Decimal
>Quantiy -> Integer (or, maybe, Decimal)
>Rate -> Not supported directly in XML Schema - its simply a pair of quantities
>Date -> timeInstance, date or time.
>Age -> timePeriod or duration
>Indicator -> Boolean
>Measure -> Decimal (or more complex type consisting of Decimal + 
>enumeration list of measurement units.
>
>The question arises as whether Representation Classes are just instances 
>of a Data Format or whether they are more fundamental than this. Please 
>try out the new Data Format form and see if they are missing something 
>that relates t o the ISO 11179 concept of Representation Classes.

-> Disagree.  The representation classes are atomic level of business 
classes conveying the information of the concept of the value domain and 
the data type.
The representation objects shall be expressed in several kinds of the 
primitive classes("decimal", "string", "boolean",etc) defined accordance 
with relevant syntax, such as COBOL, JAVA, XML. Since the core components 
for ebXML should be defined in syntactically neutral, we don't need to 
develop the set of primitive classes.

>In reviewing the latest draft of the Methodology document I get the 
>feeling that the meat of the material, which is really Section 3, is being 
>swamped by the justification material and examples that precede and follow 
>it. Would you object if I created a separate document that just tried to 
>explain the model and those things that are also covered in Section 3?

-> I understand the section 3 has not enough specification for modeling the 
business entity. It should be enhanced with expansion methodology aligning 
the deliverables prepared by BP team. I think the users may confuse if you 
provide another paper for defining the core components.

>Martin Bryan
>
>
>
>

----------------------------------------------
Hisanao Sugamata
      ECOM:
      Electronic Commerce Promotion Council of Japan
      TEL +81-3-5500-3668     FAX +81-3-5500-3660
      URL: http://www.ecom.or.jp
----------------------------------------------

=======================================================================
= This is ebxml-core, the general mailing list for the ebXML          =
= Core Components project team. The owner of this list is             =
= owner-ebxml-core@oasis-open.org                                     =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-core                                         =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-core myname@company.com                      =
=======================================================================