|
Geert,
You said, > I see many ways on the application level that could fix your use > cases today (XML databases, streaming XML parsing,...) We can design around anything. If we need to move data "off the wire" to the "destination" in 1 step we need this OID in the parser, underneath the application layer, or we must abandon XML for the wire protocol. This "on the wire" use case applies equally in the DBMS kernel that is extremely optimized to avoid temporary copies when possible. This allows XML to be used in more cases, and the implementation of an XML Database could be improved by this concept, not just application layer caching. The syntax is secondary. <element @oid='1'> is simple and syntactically backwards compatible although I understand we have this issue that some XML parsers preserve attribute order and others do not. As I once mentioned upgrading a parser is as simple as maintaining a list in addition to the hashtable or tree holding the attributes. When you add to the hashtable, also add a pointer to the list likewise when you delete from one delete from the other to sync your indexes. I will look more into how this can be done with a PI inside the element. No doubt that will add some overhead. I might be able to implement OID both ways and we can compare the difference. We need the OID for an element before we parse out the first attribute. I addressed the 'close minded' comment already in my comment to Michael Kay. We are not close minded here. Brian > Date: Mon, 31 Mar 2014 12:42:04 +0200 > To: xml-dev@lists.xml.org > From: geert@gbormans.telenet.be > Subject: RE: [xml-dev] RFC for XML Object Parsing - New Thought > > Brian, > > I can confirm that a PI is allowed anywhere in the document, > so you can consider it "scoped". > > > The 'special' #1 attribute is conceptually what we want. > That is not what you will get syntactically using standard XML tools, > so unless you want to break backwards compatibility, > you need to think about a different syntax > (and I am still unclear why you persist on it being the #1 attribute) > > I don't think it is fair to say that people here are "Closed mind"ed. > > Reading through your messages and seeing some interesting ideas on > the application level, > I am still confused as to why you want to force obvious application > level attributes into an XML2.0 recommendation > XML is a beast that serves many purposes. > None of your use cases have convinced me that your oid attribute > should become part of a future XML recommendation. > I see many ways on the application level that could fix your use > cases today (XML databases, streaming XML parsing,...) > > Maybe that explains you are not getting the enthusiasm you were expecting > > Cheers > > Geert > > > > > > At 12:02 31/03/2014, you wrote: > >Tom, > > > >I know what it means to be open minded. The concept and the syntax > >are two different things. If there is a syntax that avoids the > >attribute order issue, it needs to be studied. Admittedly, I don't > >use XML's Processing Instructions frequently so for a quick review I > >paged through > ><http://www.xml.com/lpt/a/634>http://www.xml.com/lpt/a/634 > >http://msdn.microsoft.com/en-us/library/vstudio/ms256173(v=vs.100).aspx > > > >Both examples show PI's at a global scope(selecting the XSL that > >will be applied to the whole XML document.) In both examples PI's > >are 'global', in that they apply to the whole XML document. Can > >PI's be scoped inside an element? Is there anyone listening > >@[xml-dev] that can provide a quick answer with certainty? > > > >We should consider efficiency too, since that was the motive for the > >OID design. The 'special' #1 attribute is conceptually what we > >want. At the start of every element we ask, "Which element?" If > >the question is answered, we parse directly to the destination. No > >temp variables, No DOM tree. > > > >I came to [xml-dev] specifically for comments like this one that > >force me to think of other possibilities. Does [xml-dev] go offline > >frequently? 5 Minutes down is a reboot. What causes 5 days > >down? Don't folks schedule stuff like that? > > > >As len said, after a decade a silence, not much in terms of new > >ideas are really exchanged on this thread anymore since XML is seen > >to be "fully baked". Could "Fully Baked" == "Closed mind"? Possibly. > > > >In terms of XML 2.0 thought a document would need to identify itself > >as 2.0 ONLY if it uses WRITE optimizations. It's easy enough for an > >XML 1.1 application to ignore an OID and ignore that extra data, > >however if the document uses OID for write optimizations, ignoring > >it will ignore actual data: > > > >Notice that the Blue element is in the list 2 times. > > > ><list> > > <element oid='1' color='blue' size='big'/> > > <element oid='2' color='red' size='tall'/> > > <element oid='1' color='blue' size='big'/> > ></list> > > > >with the OID optimization, the Blue element is in the list 2 times > >also - unless you ignore the OID. > > > ><list> > > <element oid='1' color='blue' size='big'/> > > <element oid='2' color='red' size='tall'/> > > <element oid='1'/> > ></list> > > > > > >Brian > > > > > > > Date: Sun, 30 Mar 2014 23:28:51 -0400 > > > From: list1@tompassin.net > > > To: xml-dev@lists.xml.org > > > Subject: Re: [xml-dev] RFC for XML Object Parsing > > > > > > As I have been following this thread, it's seemed to me that this is > > > exactly a case for a Processing Instruction. E.g., > > > > > > <?use-cache attribute='oid' element='cache-candidate'?> > > > <cache-candidate oid='check cache' ....>.....</cache-candidate> > > > > > > Using a PI gets you the same thing as order would, if order were to be > > > allowed on attributes. And after all, a PI is provided so you can pass > > > special processing instructions to a parser or processor. > > > > > > TomP > > > > > > On 3/25/2014 4:57 AM, Doug wrote: > > > > Brian, > > > > > > > > a shot in the dark, but since attribute order is important but > > > > > > > > apparently can't be guaranteed, could you perhaps stuff the oid > > > > > > > > and update time into XML Processing Instructions injected as > > > > > > > > preceeding sibblings for each element/object that has an id > > > > > > > > you care about? > > > > > > > > Doug > > > > > > > > On Mon, 24 Mar 2014 01:25:01 PM Brian Aberle wrote: > > > > > > > > > Peter said, > > > > > > > > > "Basically, it seems you believe that some number of endpoints are > > > > > > > > > going to share some deep understanding of the same object model so > > > > that you > > > > > > > > > can subsequently exploit this shared understanding to enable some > > > > > > > > > efficiencies in the XML parsing process?" > > > > > > > > > > > > > > > > > > Not exactly, it not that they intimately share an object > > model, they only > > > > > > > > > share a key to the data. Every Invoice has an invoice Number. EDI 810 > > > > > > > > > says so. When modeling that in XML set the oid= to the unique > > key(in this > > > > > > > > > case the invoice number). Attribute order matters,oid must be first > > > > > > > > > however, OID IS NEVER REQUIRED. It is as you say - an optimization - > > > > it is > > > > > > > > > an optional optimization. Nobody will be forced to retrofit into an > > > > > > > > > existing design that was depending on the principle that > > attribute order > > > > > > > > > is, was, and always will be insignificant. I can imagine that in some > > > > > > > > > existing implementations adding "oid" under the conditions that it be > > > > first > > > > > > > > > may not be simple, in other cases it's a 1 liner. If "oid" is > > > > unknown, the > > > > > > > > > data goes through the logic already in place. If "oid" is there then we > > > > > > > > > can parse triple fast. > > > > > > > > > > > > > _______________________________________________________________________ > > > > > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > > > to support XML implementation and development. To minimize > > > spam in the archives, you must subscribe before posting. > > > > > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > > > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > > > subscribe: xml-dev-subscribe@lists.xml.org > > > List archive: http://lists.xml.org/archives/xml-dev/ > > > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php > > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php |