[ubl-msc] (1) Re: UBL White Paper

[Jon Bosak <Jon.Bosak@Sun.COM>]

Tim said:

| Several times you have used the term "form" or "forms" to describe
| the deliverables of UBL.  Whilst i understand you to mean the
| constructs or data structures, "form" also has meaning in the
| sense of document and/or web forms.  We dont want anyone inferring
| that we are designing "fill in the boxes forms".  In a similar
| vein, the use of the word "component" is a bit overloaded and may
| imply connections with ebXML core components.  If its not too
| techie, i suggest constructs or structures may be a better term.

And Matt said:

| I agree with Tim regarding use of the word "forms". I understand
| that "schema" might be intimidatingly technical. Why don't we go
| with "vocabulary"?

Because "vocabulary" isn't a straight replacement for "form" and
doesn't work in some places.  I used the word "form" to emphasize
that UBL schemas are literally blank forms for business documents.
It's a legal thing.  But I recognize the potential for confusion
that Tim has pointed to.  A word that can be directly substituted
for "form" here is "format."  For example, here's what we get for
the first two paragraphs under "Documents, Components, and
Context":

   The primary deliverable of UBL is a set of standard formats for
   common business documents such as invoices, purchases orders,
   and advance shipment notices. These formats are designed to be
   sufficient for the needs of many ordinary business transactions
   and, more importantly, to serve as the starting point for
   further customization. To enable this customization, the
   standard document formats will be made up of standard
   “business information entities,” which are the common
   building blocks (addresses, prices, and so on) that make up the
   bulk of most business documents. Basing all UBL document
   schemas on the same core information entities maximizes the
   amount of information that can be shared and reused among
   companies and applications.

   In a UBL-enabled world, companies publish profiles of their
   requirements for the business documents involved in specific
   interactions. These profiles specify the business context of
   each transaction, that is, specific parameters such as the
   industries and geographic regions of the trading partners. The
   context parameters are applied to the standard formats to
   create new formats specific to a given transactional
   setting. Since these context-specific formats are based on the
   standard components, interoperability is guaranteed while
   taking into account the requirements of each party to a
   particular transaction.

I made a lot of other changes throughout to make sure there was no
confusion about the meaning of "form."  Mostly these were
substitutions of "format" for "form," but in a few places I had to
use "schema" or "document format" or something like that.  "Form"
has been left in only in places where its meaning is unambiguous.

Jon