Cart
[Home] [By Thread] [By Date] [Recent Entries]
Al Snell wrote: > What's that got to do with the textual encoding? With the *encoding*, very little. With the field or element being identified by a name, rather than a structure, very much indeed. The transform or other process which will instantiate the locally useful form of data will in this case begin from an original form identified by name rather than from an original form identified by structure or form. > Image processing programs will typically recognise a wide range of image > file formats beyond their chosen native one, and some even provide tools for > the technically advanced to pull data from bizarre image formats (I've seen > a "raw" import > dialog that asks how many byte of header to skip, what the pixel format is, > and how many pixels to read in what order). So if you see an image in a > format other than the agreed one, it can try to figure it out. This is usually the other case, where the original form is identified by structure. Please bear with me if I stress once again how the structure or datatype of that original form does not govern the form in which data is instantiated for local processing. The original form is simply an identification which allows selection of the input side of the transformation or other process which instantiates locally useful data. > Are you stating that the textuality and human-readable names on everything > make it somewhat easier for a human to figure out the format Human readability is only an ancillary advantage of the process--identification by name or name-based processing--which I am describing, and if we have name-based, rather than form-based identification, figuring out the format has nothing at all to do with it. Quite simply: instantiating data in a form usable by local processing begins from the realization that input is available. The immediate question then is, what is that input? It can be identified either by its label or its form. If the local process concludes that it is unlabeled, or that its label is incomprehensible, then, yes, it might be identified by its form. Even when it matches no form previously known to this process, it may be identifiable by something like the brute-force method you describe: > by examining examples, incrementally designing an experimental schema until > all available samples match that schema flawlessly, then assuming that's the > format of the data although the 'all available samples' in this case are simply the identifiable occurrences of particular structural patterns in the given input data instance. In any case, the point of input identification is to establish the 'original form' side of the transform or other process which will instantiate locally usable data in the form locally expected. With XML there is the possibility, at least, that the input data can be identified by name, rather than by form. If so, that name, rather than an identified form, is the basis for the selection of the original form side of the transform or other process which instantiates data as required by the local process. Yet that name is no more than an abstract label, which in the view of the local process is congruent--*via the transform or other process required to instantiate the local data*--to some equally abstract label by which the local process identifies its own required input data form: 'order' as you might use the term in Djakarta to 'order' as I use the term in New York, for example. Respectfully, Walter Perry
|
