[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 09:59:54 -0800

smil parser design
At 03:19 PM 13/12/97, Peter Murray-Rust wrote:

I agree with Peter that we should just buckle down and get on with what used
to be known as XAPI.  

But my approach would be quite different.  I think that the first step 
should be the end-user's API, the kind of thing that someone using a SMIL 
or RDF processor would need.  Such a person really doesn't want to wrestle
with entities and references and PIs and marked sections; all they want
is elements and attributes and the basic doctype info; they want the
processor to deal with entities and refs and quote marks and white space in
markup and encodings and so on.  

This would go a long way to address the whinings of the RDF & SMIL type 
people, who thought XML just meant elements and attributes.  I think that 
from their point if view, it should be, all the other stuff in the syntax 
is strictly to support authoring and management convenience.

It should come in event-stream flavor and tree flavor. 

Minimal event stream API:

1. Doctype, returns: root type, external subset system/public idents
2. Element start, returns: type, element name-value pairs, whether it's empty
3. Text
4. End Element, returns: type

Minimal tree API:

1. Document, with methods: root type, system ID, public ID, root element
2. Element, with methods: parent, children, attributeValueByName, allAttributes
3. Attribute, with methods: name, value
4. Text (presumably hiding lazy evaluation)

I acknowledge this is grossly insufficient for basing an editor on. You want
that, use the DOM.  Only a few choices have design implications:

1. How are children returned; possibilities would be to have Element and 
   Text crammed into the same class with a method for asking which is which,
   or have separate Text and Element classes, then children returns an Object
   array or a Vector, and you can find out what kind of child each member 
   is using the instanceof operator.  I favor the latter, Lark does this

2. Whether it's worthwhile putting children into, as opposed to a native
   array or Vector, a special ChildList class with enumerator and indexing
   so you can hide a lazy-evaluation behind it.  I favor the latter, the 
   DOM does this but Lark doesn't.

3. Whether the processor should be required to coalesce adjacent Text
   objects.  Suppose you have <a>foo <!--comment--> bar &ref; <?pi?>baz</a>,
   it's immensely less work if the processor can give this to the app
   as 4 Text chunks.  I think most of the processors do this now.
 
If I formalized and published this, it would look a lot like part of 
Lark's interface, but I bet all the other parsers could implement it.  
Should I? -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.