Re: [ubl-ttsc] Re: [ubl] Use cases (UBL compliance)

[Ray Seddigh <RaySeddigh100@yahoo.com>]

[Jon Bosak, Ann Hendry]
[ Perhaps useful to Chinese UBL Localization, Korean UBL Localization].

Greetings.

During the most recent TTSC call, a number of UBL use cases were brought up, including localization and localization compliance.

Here I briefly discuss a couple of related considerations that bear on the usability and adoption of UBL worldwide.

Tim McGrath wrote:
use case number 6. - (localization), is a furphy.  the localization committees are not interested in translating XML tags (or any other part of the XML componentry).  These are machine-processable labels, language is irrelevant.  What they do want to translate is the documentation. Localization is in fact and example of use case 3.

This point is especially true of runtime programs, which, in the end do not necessarily need to be translated. And this model is certainly efficient where machine execution is the ultimate goal. 

Should UBL tags be translated/translatable/transliteratable?

If the openness and extensibilty features of UBL are to be made available universally, then translatability of tags into other languages can only help. The ability of a given locale to readily understand the corpus of UBL tags, enrich it, vett it, or otherwise adapt and adopt it, is enhanced when tags are in local language. The possibilities for UBL adoption would also increase, as the standard becomes more accessible to more local developers (and users) more quickly.

- If one were to adhere to the spirit of making UBL documents readable by both humans and machines, then translatability of tags would make millions of UBL components and documents human readable, and programs more easily debuggable. Making computing artifacts human readable is a prized desideratum, as borne out from decades of useful experience with SGML, LISP, and many other computing models. 

-  It is likely that notions in business and commerce exist around the world that are not yet named or envisaged in UBL.  These have to do with the nature of local items traded, local customs for invoicing and credits, fragmentary and idiosyncratic market compositions, or local transport means and practices. On a semantic plane, tags related to these notions would not only be born and be useful in local language, but quite likely could enrich the UBL vocabulary if translated back. This would make UBL applications useful and interoperable in more places.

Take, for example the case of buying or selling a "Furphy cart". :-)

(Parenthetically, a furphy is Australian slang for a rumour, or an erroneous or improbable story. It derives from Furphy carts, used to transport water during World War I, around which servicemen would gather and gossip, spreading tall stories and rumours.                         
   
-From http://en.wikipedia.org/wiki/Furphy )

Ability to use both a "furphy" tag, and a "galvanized water cart" tag would make the item instantly clear outside its original local context and market, perhaps helping reach customers and partners where non existed before.
Availability of both tags enriches the UBL vocabulary.

Thus, in many cases it is desirable to have UBL tags be translated/translatable/transliteratable. In some cases it is even necessary, as the semantics of trade can vary unexpectedly from region to region, and inter-regional interoperability can be enhanced through tag translation.

A standards body could translate the tags itself and/or partner with locals for the translations.  It can also create a few guidelines for translation of tags.

Hope this helps.

Best Regards,

Ray Seddigh

Tim McGrath wrote:

jon.bosak@sun.com wrote:

Hello UBL TC,


Anyone who wishes to participate in the current analytical
exercise should contact Anne Hendry regarding TTSC meetings.  But
please bear in mind that the TTSC is not chartered to make any
decisions in this area.  Important as it is, the document below
should be considered a preliminary input to a much larger
discussion.

Jon
 


I. UBL User scenarios
<...>

<...>
use case number 3. (UBL label compliance) -  combines semantic and syntax interoperability.  Schematic interoperability (re-assembling UBL ABIEs) is not a constraint as they will want to invent their own.  But how does this scenario decription allow for semantic interoperability? By definition two separate 'trade and transport' domains cannot both grow UBL into the same context?  The only way we can hope for that is to have a universal conceptual model - where each BIE is defined once and once only. Even if a diverse domain (maybe the Vision Council) attempted to customize their own UBL, they could not do so without being aware of all other UBL customizations or else they could duplicate defintions.  Ultimately someone (and it could be either the CEFACT TBG17 group or the UBL TC) must own the semantic model for UBL.