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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] RFC for XML Object Parsing

I wrote all of this, to hopefully help you see worth in a worthy thing.  If you don't like this OID stuff,  and the case is closed in your mind then you don't like the flavor because of the color and you are as free as me to do things your own way. 
View 1: XML is being used to do something beyond it's  design.
View 2: XML is being enhanced to do more than the last version could.
> Someone want to blat out a terabyte of mostly unchanged data every 15
> minutes? We roll our eyes, and wonder what ever happened to delta
> updates and SOW requests.
Delta updates, Bam, watch the OID shine and kill performance numbers in the delta updates tests.
I even have the examples that spit raw numbers for folks who want to be exact about this stuff.  The delta update with an OID in extremely optimal (with options) The "State Tracking" which for a programmer is this in raw code comes with the OID.
 // true if the memory state does not sync with the  original value set by the Object Factory
 bool isMemberDirty(void *pAddressOfMemberToCheck);
 bool isMemberDirty(char *pzTagNameOfMemberToCheck);
 // true if the member has never been assigned a value, it is uninitialized
 bool isMemberNull(void *pAddressOfMemberToCheck);
 bool isMemberNull(char *pzTagNameOfMemberToCheck);
 // true if the member has been assigned a value from the Object Factory
 bool isMemberCached(void *pAddressOfMemberToCheck);
 bool isMemberCached(char *pzTagNameOfMemberToCheck);
Beyond the 50% memory reduction and Base 2X performance, due to the elimination of any copy between the memory or origin and the memory of destination, it add a whole new set of atomic level caching that all come for free with the OID as calculated data states.
You don't like my hypothetical BigData example, that is a simple proof of a need for this if XML will serve the world forever in a world where data keeps growing.  If we see cases now where XML cant do it, wont there be more when data gets bigger in 10 years?  So I stretched the XML 1.1 spec a little to solve the problem, should I be shamed for using XML for doing something that XML "cant" do?  That is one view.  Its all about how you see things.  Literally it's the difference between right and wrong.
If you ponder on distributed data structure designs like I do you would see more of a need for the OID.  Arguments in words are effective than proof in code and numbers that can be measured.  Caching makes stuff fast. 
Centralized Data gets cached to the outer edges of the network and then into the outer edges of the application.  I don't need any proof that applications can work without caching.  Caching comes sometime after the 1st generation implementation in just about every specification and application implementation that I have seen.  Can you think of any exceptions?  It seems like there is always an exception. 
Arjun - this stuff is good.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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

Copyright 1993-2007 XML.org. This site is hosted by OASIS