|
I focus mostly on database updates/queries in XML representation, the "oid" equals the DBMS index. For example - generally a column called "CustomerID" contains the value of the "oid" <Customer oid='1'> <CustomerID>1</CustomerID> ..... </Customer> The "oid" == the DBMS Index. Just as a DBMS index can be keyed over multiple columns - likewise the "oid" can be a concatenation of several columns that make it the key unique. Something like an application Config file would most likely never use an "oid". Many XML Documents, unless they are indexed in by a DBMS would not be candidate for "oid" use. Brian > From: goakes@gpsl.co > To: xmlboss@live.com; xml-dev@lists.xml.org > Subject: Re: AW: [xml-dev] RFC for XML Object Parsing > Date: Sun, 23 Mar 2014 22:55:40 +0000 > > > From: Brian Aberle <xmlboss@live.com> > > Date: Sunday, 23 March 2014 6:42 pm > > To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org> > > Subject: RE: AW: [xml-dev] RFC for XML Object Parsing > > > > Anyone else - If we took caching so seriously in HTTP, why should we > >avoid it > > all together in XML? > > > I'm still struggling a bit with the use-case here. In "my world" we deal > with > XML for documents, XML for data, XML comms and XML configuration files. > > 1. XML for communications - largely transition/ed/ing to JSON. > 2. XML for configuration - no need for caching. > 3. XML for data - updates made to database, XML used simply as a > serialisation. > 4. XML for documents - updates made by authors/editors. > > Documents which are authored or maintained in XML format are rarely > delivered in > XML form, common formats are HTML, PDF, EPub, etc. So any caching concerns > on the > delivery side are handled by the delivery mechanism. > > I can think of a few edge cases where an XML caching mechanism may be > vaguely > useful but I am intrigued about your use case for this. I am probably > missing > something. > > // Gareth Oakes > // Chief Architect, GPSL > // www.gpsl.co > |