Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@f...] 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.
|
