[
Lists Home |
Date Index |
Thread Index
]
bob@objfac.com (Bob Foster) writes:
>3. The proposal is certainly a pain for an editor provider. It
>effectively introduces an extra stage of processing in between b and c
>in a) detect encoding, b) translate encoding to Unicode, c) parse XML.
>An editor must make this extra stage an option. Many users will prefer
>not to do the latter translation, so they can see the "entities" as
>entities and edit them as such.
For me, there's an odd story here. The XML spec was written in such a
way that many (most) parsers didn't provide access to entity references,
especially when they appeared in inconvenient places like attribute
values.
To get around that, I first wrote a pre-processor that handled documents
as text and did entity work there. Next, I wrote a parser and an API
that lets me get to entity references in particular contexts, so I could
(potentially) do things like process entity references in XHTML content
as XHTML, MathML as MathML, and Joe C. BlowML as Joe C. BlowML.
Now, entity references seem to be vanishing into the encoding. If I
open these documents in their declared encoding, the parts on which I
wanted to work all vanish. I guess I can still open them as plain
UTF-8, but now the entity references live in this murky state, neither
XML nor Unicode.
I certainly don't want to do the extra translation, even when
"UTF-8+bogosity" is specified - that would void the whole point of the
work I was doing - but I'm not sure what state that leaves the
information I'm providing to developers. Suddenly, tools I'd designed
to go beyond the requirements of simple compliance are now uncompliant,
sort of maybe possibly I can't really tell.
Yecch. Good thing I'm working on my finish carpentry skills.
|
