Local practice and process (was Re: Two different sets of experiencesabout non-English identifiers)

["W. E. Perry" <wperry@fiduciary.com>]

"Christopher R. Maden" wrote:

> If the Korean bank is using a standard financial document type, then the element
> type names should be standard.  No problem.
>
> If the Korean bank is using a standard financial document type but with
> localized element type names, then the transformation is trivial.  No problem.
>
> If the Korean bank made up their own document type and needs to merge this
> information with the American bank's information, then this is going to be a
> pain in the neck *regardless* of the element type names - serious analysis is
> needed to determine the mapping between the structures.
>
> In this case, the language of the markup is irrelevant.

Chris is correct, but his response goes to the heart of a problem far larger and
ultimately more contentious (shudder!) than the need for or desirability of native
characters in XML names. In any application where marked up instances are
subjected to more than the most trivial processing, a fundamental design decision
is whether the markup of those instances should reflect the assumptions of local
practice or should defer to some 'industry standard' expectations. Over the past
three years more than 2000 vertical market data vocabularies have been published,
and evangelized, in an XML form. The assumptions made in these standards are every
bit as arrogant and exclusionary as a mandate that XML names be limited to
English, or to ASCII, or to Latin character sets. In the name of 'shared
semantics' such standards insist that markup intended for interchange between
enterprises should describe agreed, common denominator data structures which, by
implication, anticipate some universally standard processing. But if the Korean
bank has done what Chris' third possibility implies, they have used markup to
describe their own idiosyncratic, perhaps unique, understanding of the document
instance and, implicitly, to anticipate what may be a uniquely local processing of
that structure. This goes directly to the question of what markup is, and is for.
I believe passionately that markup should provide the most accurate and the most
convenient possible means to describe what is each markup author's unique
understanding of an instance and to convey by extension that author's perhaps
unique expectations of how that document should be processed. Once we move any
distance from that absolute position we are on a slippery slope which leads
quickly, and with apparent reason, to restrictions on XML names, among others,
grounded in expectations which flow from a premise of 'shared semantics' rather
than a first principle of providing the best tools for the expression of each
author's unique values, and value added. Taking that absolute position, though,
commits us to the *very* difficult work of designing processing models which can
do something meaningful with one author's instances in an environment designed to
execute processes based on very different assumptions. If, with this 'Blueberry'
debate, we are facing up to how much idiosyncrasy, even uniqueness, we are obliged
to accommodate when we make local practice paramount, then I shall consider this
discussion the most significant milestone since the adoption of XML 1.0 itself.

Respectfully,

Walter Perry