[
Lists Home |
Date Index |
Thread Index
]
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@talsever.com alicorn@mindspring.com
The less I seek my source for some definitive, the closer I am to fine.
-- Indigo Girls
|
