[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal

  • From: Tim Bray <tbray@t...>
  • To: xml-dev@i...
  • Date: Sat, 13 Dec 1997 18:41:10 -0800

Re: YAXPAPI (Yet Another XML Parser API)- an XDEV proposal
At 09:01 PM 13/12/97 -0500, David Megginson wrote:
> > What's the boolean?  I don't think the application author should
> > to have to deal with anything but the name and value of attributes.
>The boolean tells whether the attribute was specified or defaulted.  I
>include this to allow people to do useful XML-to-XML transformations.

No.  Not of interest to people who just want to see elements and
attributes.  The whole point of using an XML processor is that it
takes care of these details for the application programmer.  Leave it 
out for now.  If you want XML-to-XML you need a lot more, go use the 
DOM.

> > >  data(XmlParser, String) 
> > I feel that the 2nd argument should not be a String.  It is a recipe
> > for disastrous inefficiency if the processor has to cook up a 
> > java.lang.String object for every little chunk of text.  
>
>The overhead isn't that bad with Ælfred because I coalesce my data
>into the largest chunks possible before allocating the String.  I
>think that returning a char[] array would be confusing for users

that's a fair point; the correct solution per design principles
is to have a Text class that could give you a String if you
asked it; since many applications will ignore the comment of many
elements, it seems vital not to have an interface that makes
lazy evaluation impossible.  So I think you have to go for either
the char[] trick or another class.

> > Lark has a thing where if any callback returns 'true', the
> > parser drops out of its loop... which is awfully useful and easy
> > I think.  Lark will also re-enter, but this need not be a requirement.
>
>Awfully easy with a DFA-driven parser, but trickier with a
>recursive-descent parser like Ælfred.  

But it seems completely unreasonable, if I call the parser mainline,
not to have a way to get control back.  I guess you could get the
client callback to throw an exception... blecch.  If exceptions
are going to be thrown, it's better to hide all this stuff within
the processor and not make each application do it. -Tim


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.