[
Lists Home |
Date Index |
Thread Index
]
Amelia A Lewis wrote:
> Create a TypeHandler in SAX. This turns out to be a problem. Clearly,
> you want to be able to signal a type (an identifier for the type) and a
> value; this means that there is significant overlap with the "regular"
> handlers. Double-reportage, in short, and the usual problems of
> synchronization. The problem becomes acute if there is a desire to
> create a mostly-PSVI, falling back to plain-old-content if the content
> is well-formed, but not valid (this happens a lot more often than the
> folks who write the specs seem to think). Issues arise of: does the
> type information arrive first or last? How do multiple extensions
> interact? What order are the information items delivered in, when
> multiple extensions (or the core and one or more extensions) overlap?
> This is a problem for SAX and similar streaming/message-oriented APIs,
> but such APIs tend to be best-suited for the parse.
i don't know sax too well, but shouldn't there already exist such a case
for 'attributes' and 'namespace attributes' of an element, so that when
an attribute declaring a namespace is being parsed, two events could be
raised? how does handle sax this?
and yes, introducing infoset extensibility certainly would make any api
more complex, even though i think that the issues that were being raised
could be solved. and: if you didn't need or want access to the infoset
extensions, than you could still use a good old sax1/2 parser.
cheers,
erik wilde - tel:+41-1-6325132 - fax:+41-1-6321035
mailto:net.dret@dret.net - http://dret.net/
computer engineering and networks laboratory
swiss federal institute of technology (eth)
* try not. do, or do not. there is no try. *
|
