OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: SAX2: relative ordering of startDocument() & startDTD() events?

[ Lists Home | Date Index | Thread Index ]
  • From: David Brownell <david-b@pacbell.net>
  • To: David Megginson <david@megginson.com>
  • Date: Wed, 23 Feb 2000 20:18:06 -0800

David Megginson wrote:
> David Brownell writes:
>  > > How about if we renamed them to start/endExternalEntity and forgot
>  > > altogether about signalling internal entity boundaries?
>  >
>  > That'd work for me.  (Just saw this note, sorry -- mailer troubles.)

I forgot to mention:  it's not "external" entities that are the issue,
so some other name would be needed:

	<foo> &bar; </foo>

can be sanely reported regardless of whether "bar" is internal or
external ... so some other rename would be needed to address such
issues.  {start,end}ContentEntity maybe?

>  > Is there another source of a requirement for such boundaries, other
>  > than partial DOM support?  Because I'd as soon not reinforce that
>  > troublesome part of DOM.
> The only reason that I'm including this is that the DOM implementors
> want it very, very badly.

I for one would prefer (very, very, very badly -- that's much more serious
than just "very, very" ;-) to see it go away completely.  Both DOM and SAX.

The complexity of exposing entity inclusion in any usable way is huge,
and the way they turn a DOM into something that's partly read-only is
just a huge pain in the posterior.  (And no, the 'traversal' L2 stuff
doesn't help in the least.  Children of entity refs, if there are any,
are readonly -- the only way to deal with them is to rip them out by
the root, like some weed.)

Keep in mind that DOM doesn't have complete APIs for Entity or EntityRef
nodes in any case ... this is just the start of a huge mess of features
to be designed.  A mess that I've not seen any benefit to having, even
after having had access to it for quite a while.  Best IMHO not to push
that mess into any "standards" type of context, particularly when even
the "customer" of this API (DOM) isn't really ready to use it (e.g. by
having APIs that let anyone populate Entity/EntityRef nodes, with fully
portable APIs without the huge implementation leeway now available.

>  > Were this feature to stay, would those boundaries need to be reported,
>  > or would this be exposed in a feature flag?  Or would the meanings
>  > of the existing {ex,in}ternal-entities feature flags cover that issue?
> I assumed that the whole LexicalHandler would be a package deal (and
> one that 99% of apps could happily ignore).

Hmm, I guess I didn't see this, at least with the entity reporting.

- 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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS