Re: [xml-dev] RFC for XML Object Parsing

[Michael Kay <mike@saxonica.com>]

> 
> If I understand the oid attribute correctly, the receiver may maintain a mapping from oids to element nodes in its internal representation, and what the sender must guarantee is that if the oid is the same, the other attributes, their values, and the content of the element are the same as before.  


Thanks John. So actually the recipient can do what it likes with it, and hashing it to a memory address is just one implementation possibility?

But uniqueness demands context. What scope is the OID unique within? All documents that the recipient has processed, ever? All documents from the same sender? All elements within the same document? (If it's from all senders, then how can a sender make an invoice number unique?). 

My understanding is now that the OID means "you might already know this element. If you do, you can ignore its content. If you don't, process it in the normal way, and make a note of the OID in case you ever see it again". Is that right?

Next question: where does the claim of 3-fold performance improvement come from? Isn't that entirely dependent on the number of cache hits, i.e. highly variable depending on the workload?

The parsing optimization presumably requires that if the OID is recognized, then we can skip to the end of the element with minimal parsing cost.

Conjecture: I suspect that this can be achieved without departing from standard XML. An application using a standard Stax parser could probably achieve most of this benefit.

Another alternative would be a call-back protocol. Don't send the full invoice, just send the invoice number. If the recipient wants to know more about this invoice, they send a message back to ask for it. Also known as hyperlinking.

Michael Kay
Saxonica