[
Lists Home |
Date Index |
Thread Index
]
- From: David Brownell <david-b@pacbell.net>
- To: Michael Fuller <msf@io.mds.rmit.edu.au>
- Date: Thu, 24 Feb 2000 21:15:13 -0800
Yes, from my perspective the added "optional" handlers are one of the
primary reasons to want SAX2. Namespace stuff layers cleanly (like the
ParserAdapter), but those new handlers can't possibly be layered.
Michael Fuller wrote:
>
> So. Question. What do we need to do to get LexicalHandler to completion in
> an acceptable timeframe?
The issue that this thread sort of latched on to is that {start,end}Entity
callbacks produce garbage for refs _inside_ markup constructs. This happens
with both parameter and general entities:
<!ATTLIST foo %std.attributes; %simple.xlink.attributes;>
<element att1="this &that;" att2="&fija-flag;">
Basically, it only works fine for stuff between constructs, though the
first of these examples make me wonder about that (with respect to PEs):
<!ENTITY % foo SYSTEM "foo.mod">
%foo;
<![ foo.flag [ ... ]]>
<element> &interior; </element>
Proposed resolutions this far include
(a) some unidentified name change, associated with a
spec change to make clear that these callbacks only
report entity expansions in "content" or "markupdecl".
(b) just provide an "entityNotSkipped()" style callback,
matching the current ContentHandler.skippedEntity()
callback [ hmm, why is entity info spread between two
interfaces? ];
(c) just delete start/end Entity calls
(d) ship it broken (e.g. as-is)
My preference is for (c) and I strongly believe that (d) is wrong.
If anyone really _wants_ partial support for exposing entities, and
has a proposal to fix this that's still "simple", it'd be good to
hear about it ...
I also have issues with startDTD(), but as I'm working around them for
now they're clearly a lower priority than API calls that can't be
used at all, as currently specified.
> Anyone care to explicitly describe the problems
> that need to be resolved? (I'm not completely clear what they are myself.)
The OASIS archive gives me 404s, so it's understandable ... :-(
- Dave
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************
|