[
Lists Home |
Date Index |
Thread Index
]
Hi Rick,
Rick Jelliffe wrote:
>The downside is that it does not
>provide any mechanism for fine-grained annotation of individual nodes
>in the original document (apart from type-tagging). This may not
>be a requirement given (for sake of argument) that we are more interested in
>knowing that a node is valid rather than telling later processes how to treat that node.
>
>
I think I should have made a clearer distinction between the three usage
patterns I outline in the proposal -
[a] added meta-data, as when you SchemaProcess() a root element and
then query SchemaResults() on that element *or any child node* to get
type or other meta-data for the node in question. This is what I regard
as the base case, and what is outlined in the first use case.
[b] alternative instance data, as when Default values are added - in
this case you SchemaProcess() an element and then substitute the
SchemaResults() from *that* element as instance data for onward
processing, though still using usage [a] to query meta-data on this new
instance data, and
[c] piped processing, where the results of one type [b] processing
step are used as input to another. The third use case is meant to
illustrate types [b] and [c] usage patterns.
In summary, case [a], which is what I think you are asking for above, is
in fact the basic usage, and what I meant by the first 'L' in Locally
Linked Infosets.
Francis.
see http://www.redrice.com/xml/LocallyLinkedInfosets.html
--
"Never mind manoeuvre, go straight at 'em." - Admiral Horatio Nelson
|
