[
Lists Home |
Date Index |
Thread Index
]
Discovery by output has the aggravation that the output may
not be regular from instance to instance. Or one could
say that one should be looking at the output of another
process that defines the output of the others. 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. 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.
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.
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.
len
-----Original Message-----
From: W. E. Perry [mailto:wperry@fiduciary.com]
Absolutely agreed. I do try to extend this point, however, by noticing that the most
accurate and effective discovery about a process is in the examination of its output.
You see precisely what you are getting, not only in the instance content, but in its
manifest structure. Furthermore, these outputs as XML, or even as HTML, are documents
and can therefore be published at URLs, allow the whole system of interprocess
communication to be managed, as the RESTies advocate, with the general-purpose tools of
http.
|
