[
Lists Home |
Date Index |
Thread Index
]
james anderson <james.anderson@setf.de> wrote:
| Arjun Ray wrote:
| > james anderson <james.anderson@setf.de> wrote:
| is the issue that "multiple external names may map to the same local name"
| _simultaneously_?
Yes. That is the general case, and much of the point of the Architectures
idea.
|> Thus, the correct general approach is outside-in ("where is my value?")
|> rather than inside-out ("who gets this value?")
|
| unless there are simultaneous many-to-one external-to-local correspondences,
| then "outside-in" is no different than "inside-out"
True.
| > specific resolver/extractor == (URI x external-name) -> local-name
|
| i can imaging accessors which are intended to serve as the basis for
| "in-line-mapped" transforms which would use functions of this form, but
| their effect would be to transform the external names in the xslt (or
| the like) into the local name set on the fly.
Thinking of all this as "name transformation" is to a great extent missing
the whole point. Names are instrumental: they are the means by which you
address/access values. The "boxes" that hold the values are the local
names - the actual instance markup. Your schematic understanding of a
document and processing of it, however, are governed by the names *you*
know. Consequently, the issue for your program/environment (which is
ultimately concerned with semantic manipulation of *values*) is not what
those local names are, but how your names (which are "external") map to
those local names in order to get to the values, ie. which boxes have the
values for your names? This is a purely instrumental mapping, nothing
ontological about it.
| in which case, a process/transform which is to be applied repeatedly to
| documents based on a differing ontology/taxonomy/name-set should itself
| be tranformed inside-out before being applied to the target documents.
You could do that if you wanted to, yes. You'd invert the maps XMap-style
into a set of one-to-many maps of the form
local-name -> { (URI1, name1), (URI2, name2), ... }
but I'm not seeing the value of such an exercise.
| does an assertion of the sort, that {}xyz is to be associated, even
| simultaneously, with {http://www.w3.org/1999/xlink}href and
| {http://www.w3.org/1999/xhtml}src have any semantic content during the
| transformation process?
I don't know, and I don't think so. Since it isn't about transformation
(at least, to my way of thinking) but about resolution, a semantic for the
*fact* of simultaneity doesn't seem necessary. All that the markup would
try to say in the general case is something like "this value is described
by this (name) OR this (name) OR ..." rather than "this value is described
as this (name) AND this (name) AND ...".
| is xmap is intended to act more like the following?
| (whereby the difference is not the acons, but the sublis.)
Ah, missed that, thanks. My CL chops aren't that good, but that looks
about right. One thing, though. The XMap attributes are probably best
suppressed in the "output" - they were there only to get the (merged?)
infoset right. You are thinking in terms of infoset processing, right?
|
