2/02/01
Technical Open Issues
Language
My question is the following.
1.) There are a few way to write "Address" and "Party Name" or some string entity in some counties.
For example, You know, When someone write Building name in "Address" by Kanji character. sometimes, In Japan, A customer will add the information of ruby string with Katakana or Hiragana which has phonetic meaning.. You can
find the sample about this in attached bitmap of this mail. Most of transport company's sending envelop has these information. Is this possible to add these information in some entities?
2.) If it does not have in this current spec, I would like to request to discuss the way of adding ruby information or the rule of adding these information.
Martin Bryan’s response -
The default data type for Building name is likely to be an XML simpleType that contains a string. In XML this maps to the UCS character string, which would contain, for example, the Kanji character. If you need to add a ruby
to this default definition then you would define a context in which the Region was Japan. For this context you would extend the model of Building name to be of type mixed, with an embedded ruby element being used to extend
the base model of string that applies to the PCDATA component of the predefined model.
Language standard
ISO 639 is somewhat incomplete. You might want to consider adopting IETF-1736, which allows for the extension of ISO 639 using reqional qualifiers, so that you can cover things like Native American languages.
Party identification code
Line 20: Party Identity aggregate. Is Identification Code an enumerated list of values identifying the authority responsible for assigning the Identifier? If so, the discussions ongoing in TR&P under the thread "PartyId and Context" re: identifier authorities (e.g., UN/EDIFACT D.E. 0007, ASC X12 D.E. I05 and ISO 6523) are relevant here. See
Code or Text
As we always have the endless discussion about codes or textual information, and after some practical implementations, it seems to be a valid solution to have both. This means, that a code always is accompanied by a text (or "name"), as we have used in the insurance components:
Telephone number
Line 55: Communication Point aggregate. Is breaking out the telephone number into Telephone Country Code, Telephone Area Code, Telephone Local Code, and Telephone Ext really necessary, esp. when ITU-T Rec. E.123,
Notation for national and international telephone numbers, exists for formatting them? See some comments on telephone numbers at which also talks about dates and times and brings us to:
Date/time
Line 79: the Date/time aggregate. All of the base components Date, Time (and their respective formats) and Time zone offset can be accommodated in one field by conforming to the ISO 8601 Date and Time Format; see
XML Schema Part 2: Datatypes already support many ISO 8601 Date and Time Formats natively.
Duration
Durations are already built into the W3C Schema specification: timeDuration represents a duration of time, like the [ISO 8601] extended format PnYn MnDTnHnMnS. Like everything I pretend to know about schemas, I found this out from Martin Bryan's "Datatyping for Electronic Data interchange - Draft CEN/ISSS Workshop Agreement," at
Martin goes on to say:
Time durations are periods expressed in terms of years, months,
days, hours, minutes and/or seconds according to the Gregorian
calendar. These are expressed as an integer (or decimal number)
followed by a letter. The letter P is used to identify the
start of the period definition, the letter T being used to
identify the start of the time components within the period.
The basic format of a timeDuration definition is PnYnMnDTnHnMnS,
where n is the appropriate integer/decimal. Values can be
truncated by omitting one or more of the lower order numbers and
the associated qualifying letter. If the number of years,
months, days, hours, minutes, or seconds in any expression equals
zero, the number and its corresponding designator may be omitted.
The whole of the date can also be omitted by following the P with
a T.
This is different from the timePeriod type, which I think must be an ISO 8601 Extended format period of time identified by its start and end dates, e.g., l985-04-12T23:20:50/1985-06-25T10:30:00.
Bit/Images
as proposed by Finance:
Add Image/Picture AggregateImage/Picture / Aggregate
Format / Basic / 0..1 / CF / The electronic format of the image (e.g. jpg, pdf.,…) / Core
Identifier / Basic / 0..1 / CF / The name or alpha-numeric string which identifies the image. / Ext
Image / Basic / 0..1 / CF / The data which makes up the image. / Core
The Image/Picture Aggregate proposed by Finance includes three components: (1) the Format - the electronic format of the image (e.g. jpg, pdf.,…), (2) an Identifier - The name or alpha-numeric string which identifies the image, and (3) the Image - the data which makes up the image.
The intent is clear - in that business documents will have all sorts of reasons to refer to images or other supporting documents in the form of jpegs, Adobe Acrobat pdf files, Word documents, etc. But I would suggest not including the actual image or document within the business document itself. Instead, an *external* reference can be made to
another MIME body part within the ebXML TR&P MS payload using a "cid" URL, described in the Content-ID and Message-ID Uniform Resource Locators; see RFC 2392 at For example, a JPEG picture image would be "attached" to the MIME payload envelope, and indirectly referred to by the business document using the URL string "cid:m":
--Boundary_(ID_rZCQj0ia1UzTFR4Q7NJaBg)
Content-ID: <m>
Content-type: image/jpeg; name=DSCN3385.JPG
Content-transfer-encoding: BASE64
This is consistent with the way TR&P refers to external MIME parts, where Section 8.3 - Manifest element - within the ebXML Transport, Routing & Packaging Message Service Specification (Version 0.91), at
shows use of XLINK to refer to external documents.
Product/service
I think the definition of Product/service may suffer from a common conceptual problem, the lumping together of product definition and product instance. For example, the definition of an automobile model (e.g. Flapmobile Deluxe Roadster) vs a particular instance with a Vehicle Identification Number sold to a particular customer. Or the definition of a food product with a SKU vs a particular bunch of products on grocery shelves with Lot IDs. Or a flightnumber vs a seat on a particular leg of a particular trip. Or a room number vs a particular stay.
The BP Metamodel makes this distinction as EconomicResourceType vs EconomicResource (instances of
the type). EconomicResource may be too abstract for core components, but the distinction between type and
instance may be necessary. All ERP systems make the distinction in one way or another - the type level is often
called "Master", e.g. "ProductMaster" vs "Inventory" or "Lot".
You should have checked the EDIFACT PRODAT message type prior to saying that there is "been a bit of a shortcoming in the trad EDI world, when it comes to product 'classification & identification'". Indeed There is a very well working capability to classify and identify products and their Characteristics. Maybe you shoul have a look at this message type. The EWG wMsub working group Materials Management dealt quite a long time in these issues and developped a message type which even wirks in the provision of complexSystem's masterdate including "physical product/service descriptions/attributes," AS WELL AS "descriptive latitude (which may be more of a code list-s- issue) towards allowing for the 'market aspects' of a product".
from Marianne and Paula:
From the general comments we received with no specific changes, need to review product/service to see if it meets their needs.