[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: parser models
Hmmm. On Mon, 2002-09-23 at 23:24, Simon St.Laurent wrote: > Elliotte writes about: > > Adding the features necessary for editors would immensely complexify > > an API for other, more common use cases. Editors justifiably need a > > different API. > > I'm not sure that I accept that the difference between "editor" APIs and > "processing" APIs is that clean-cut in practice, though there's > certainly a cultural divide between developers who are creating markup > by marking up information (which I think you're categorizing as > "editor") and developers who expect information to come prepackaged in > neat little boxes. I'm not sure that that's what "editor" API means here. I think, instead, that this points up the difference between a lexical API and a syntactic API (Arjun Ray usually shows the next level, a semantic API of sorts, in his examples). The lexical API ought to be concerned with things like the XML declaration, and ought to know where the line breaks are inside tags, and the order of attributes, and whether the attribute values are quoted with singles or doubles. Likewise, it ought to know whether someone has embedded some cruft like this: <![CDATA[Some marked <em>up</em> text.]]> or like this: Some marked <em>up<em> text. Infoset, SAX (with some escape mechanisms), and most other existing APIs work on the syntactic level, with a greater or lesser degree of abstracting away the pointy brackets (plus all of the above lexical information). If I have an XML editing tool, I have the right to expect that it isn't going to change things to suit itself (it may have some sort of menu that sets a style, while still operating on a syntactic level, in one form of editor, but I'm likely to be dissatisfied if it changes anything without my permission). It shouldn't change the order of attributes, and it shouldn't change the line breaks that I put in between attributes in order to get them all to read nicely to a human. A lexical API might be able to signal potential problems, but it shouldn't refuse to deal with a file. I want to *use* that API to fix the broken file. To the best of my knowledge, there are no public lexical (editor) APIs. Building a lexical API on top of a syntactic one is ... backwards. It is perfectly easy to imagine, for instance, LAX: the lexical API for XML. This would have different sorts of events, though. Perhaps it would have "leftPointyBracket()" and "nameCharacters(char [])" and "tagWhitespace(char [])" and "attributeValue(char, char [])". That is, it would supply tokens, rather than a completely raw string (imposing a certain amount of order), but it wouldn't have abstractions as large as startElement(), which requires that the open tag be properly delimited, correctly named, and suppresses information about lexical events happening inside it. It would be easy to then pipe that into SAX. I don't know if an in-memory API corresponding to such a ... lax parse (oh, re ... lax. You knew that was coming, right?) is possible, though. I don't yet know of a public in-memory API that I consider to be really good for modelling XML at the syntactic level. Amy! -- Amelia A. Lewis amyzing@t... alicorn@m... The less I seek my source for some definitive, the closer I am to fine. -- Indigo Girls
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|