OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Locally Linked Infosets approach

[ 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.


see http://www.redrice.com/xml/LocallyLinkedInfosets.html

"Never mind manoeuvre, go straight at 'em." - Admiral Horatio Nelson


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS