XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
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 - 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







[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