[
Lists Home |
Date Index |
Thread Index
]
Wayne Steele wrote:
> Company A can use one set of GIs, and Company B can use a different set. They
> can differ on the old element-vs-attribute question, and whether all lowercase
> is better than CamelCase. Useful interchange of documents is only slightly
> impaired, as each can use XSLT to translate to the "local standard"
> representation.
>
> XSLT enables everyone to use the syntax they like.
Yes, BUT:
There is no question that the XSLT solution is a more promising basis for
interoperability than a priori standardization of markup vocabulary. The
residual problem with XSLT for translation to "local standard" is in its 'push'
nature. XSLT transformations are premised on an intimate understanding of the
source tree and are designed to render that source tree into multiple output
forms--as understood from a source-tree-centered perspective. "Local standard"
as properly understood is just that: locally understood. The understanding of a
target locale from the viewpoint of a source to be transformed is a different
local understanding. Unless we are to return to a priori agreements, the
understanding of the target at the point of XSLT transformation will predictably
differ from the truly local understanding at that target.
This predictable misunderstanding is unfortunately fatal to the use of standard
XSLT for the purpose that you so hopefully describe. If a source-centered
transformation is to be the only one applied, then the uses of the transformed
data are strictly limited to those perfectly understood at the time and place of
transformation--that is, at the source. By a different route we reach the same
impasse as with a priori standardization of vocabulary: nothing can be done
with given data at the target which is not as understood at the source. Yet the
purpose of distributing the processes--and necessarily of using an locally
appropriate data form for each--is to harness particular autonomous expertise
into a larger endeavor. That advantage is obviated if all that might be done
with transformed target data is what is already perfectly understood at the
source of that data before transformation.
Local understandings of data properly arise from particular local
uses--processes!--which operate against that data. This requires that a generic
transformation utility must share those local understandings in order to render
data accurately into that locally comprehensible form. As a practical matter,
this requires a 'pull' process at the target side of the transformation,
designed to render multiple possible sources into a given outcome. A significant
advantage of that topology is that such a transformation, colocated with the
processes to which it supplies data, may share their private understandings of
their own data needs, not only for determining the exact form of data which it
should render, but also for performing accurate sanity checks upon what is does
produce.
Respectfully,
Walter Perry
|
