[
Lists Home |
Date Index |
Thread Index
]
"Bullard, Claude L (Len)" wrote:
> Discovery by output has the aggravation that the output may not be regular from instance
> to instance.
Which, if it is the case, is already a feature which the consuming application has to deal
with anyway. And, yes, this does happen in the real world (it is true in some months of as
much as 20% of the data which my applications must consume) and it is a problem utterly
incapable of solution by schema, or in the general case by any fixed a priori agreements.
> Or one could say that one should be looking at the output of another process that defines
> the output of the others.
Why add this layer of indirection when we already understand that we are not relying on the
authority of a priori agreements, and a third party which merely makes empirical
observation of the behavior of processes is not doing anything which an XML-consuming
application could not, and should not, do for itself.
> This is something like the process of analyzing print documents to create schemata for
> them. One has to be sure the set is exhaustive or one comes back to rework.
Perhaps so, if we were analyzing them in order to derive generalized schemata, but I
propose that this is emphatically not what we are doing. Instead, the XML-consuming process
is examining an instance document to determine whether in that particular instance, or in
some other document which could be located and fetched based on the information in that
instance, is there what the XML-consuming application requires to instantiate some
particular bit of data which it requires for one instance execution of its processing.
> As said in the past, even when schemata aren't used in the communication pipeline, in
> the design pipeline, they can be invaluable. If as an output of that process, one gets a
> definition which is exhaustive, that is, any transaction will be valid under it, then it
> is better to read the schema.
The design of an application is in large part the design of its appropriate internal data
structure. If we are talking about the schema for that structure, then that is emphatically
not the schema which might be considered to govern the form of document interchange between
processes and thereby to enforce a 'contract' at the input or invocation interface side of
an application. Indeed, my primary point is that we cannot rely on any ostensible
input-side schema, even when all observed input instances conform to it, if our design goal
to to build an application predicated on the best implementation of its own expertise,
including a necessary expertise in input data collection and instantiation.
> I say where namespaces are used, there should be a document somewhere but I prefer such
> documents for any XML output.
> If the http: URI is used, it should, in good conscience, point to a document should
> inspection ever be required.
Why? What can it possibly give you except an accurate description of an instance which you
could get directly? And you run the considerable risk that the schematic is out-of-date or
simply doesn't describe an exceptional instance which is the thing of interest to you.
> Sure, there are XML instances without very long lifecycles or when opened, are glaringly
> obvious as to what is intended. Every situation has exceptions. To me, the spec is fine
> as is by not requiring such, but we are better off by the practice. Humans still have
> some decisions to make.
Indeed they do, but in my opinion they should be basing those decisions on the data
instances which they have actually got rather than upon some authority which purports to
govern such instances. (This gulf between revelatio and auctoritas is certainly nothing
new).
Respectfully,
Walter Perry
|
