[
Lists Home |
Date Index |
Thread Index
]
Arjun Ray wrote:
>
> ...
>
> | > 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.
the program which transforms itself once to generate specific versions adapted to the names used in respective docment forms will have an advantage over the
program which remains static and transforms each document.
>
> | 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?
>
actually, i'm thinking in terms of transforming the processor.
...
|
