Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Local practice and process (was Re: Two different sets of experiencesabo
 "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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
