RE: History: Question on C14N list of nodes instead of subtrees

To be fair c14n did go to REC and while xmldsig didn't because of 
bi-institutional process lag it garnered at least 12 implementations in 
that time! XPtr still isn't a REC and I think has ~1 complete 
implementation. (I was looking into XPtr *because* there's still some 
contention about its status and advancement so I think we made the right

decision!)

<jb>agreed</jb>

I understand this aspect but I'm wondering (in a muddled way) why "the 
result of the XPath expression id("E") is a node-set containing only the

node corresponding to the element with an ID attribute value of "E".
Could 
one do the same with a nodelist as a list of  subtrees (if necessary)
where 
each subtree corresponded to an "orphan node" subtree resulting from the

expression, otherwise the subtree is the subtree resulting from the 
filtering and there's parent-child contiguity? (I'm not saying I like
this 
or that's it better just clearing some cobwebs from the attic now that
I'm 
thinking about XPtr not being widely implemented and (independently) 
XPath2.0 (which is base on Infoset...))

<jb>This would eliminate the ability to exclude portions of each
subtree.

On a complete separate note, Donald recently proposed the use of the
following:

(id("foo")//. | id("foo")//@* | id("foo")//namespace::* )

for those situations when one has an id attribute that identifies a
subtree (which also implies a validating processor).  I would think this
expression would be a fair bit faster (if the application context
allowed identification of a desired subtree by an id attribute).

John Boyer
PureEdge Solutions Inc.

Received on Wednesday, 23 January 2002 19:23:28 UTC