On 2/19/02 2:20 PM, "John Utz" <[EMAIL PROTECTED]> wrote: > I'll put my oar in at this point, because i think james has put this > together quite nicely..... > > On Tue, 19 Feb 2002, James Berry wrote: > >> I¹ve heard at least two concerns/proposals regarding what needs to be >> addressed in this proposed binding: >> >> (1) Normalize names per Tinny below: IDOM_Document --> DOMDocument, etc. > > key clarification needed about intent: > > Does the API distinguish the 'flavor' of DOM? > > From an abstraction standpoint, isnt distinguishing > between DOM flavors a bad idea? in my perfect geek world, > i should reap the benefit of a new super-duper DOM > implementation without having to recompile. Is that > unreasonable? Or does it conflict with another issue that > i am unaware of?
In the perfect world, yes, you might be able to swap out DOMs. But the IDOM changed the interface and programming model, I believe, not just the implementation, so it needed a new name to reflect the new interface. In looking for a standard C++ binding, though, one might ask: is the interface opaque enough to allow different underlying implementations to be built atop it? Or does the interface presume the implementation? <New mail from Lenny Hoffman goes into more detail here...> > >> (2) Alter ³IDOM² memory/ownership model such that memory belongs to the >> document rather than to the parser. Or provide a means of disassociating a >> document from the parser so that when the parser goes away it will not >> destroy the document. I would advocate that this should be done implicitly >> on successful completion of a parse: at such point the document becomes >> ³stand-alone² with no further ties to the parser; if the parse fails, >> there¹s no document and so the issue is moot. > > key clarification needed about intent: > > Is implicitness with respect to mem management a feature or a bug? > > If you were processing a group of docs with an eye > toward a future group modification, would you be surprised > and dismayed to discover that this disassociation had > occurred? > > Yes, i am talking about an issue that doesnt exist yet. > But, if you buy my argument about abstraction, then an app > written today could still be in use a few years from now > when editing of DOM's in mem could be widespread. > > I recognize that this discussion item is a response to the > *opposite* problem raised by jason stewart: 'who's > responsible for freeing an unneeded parser?' > > It seems to me that this association behavior should be > settable as a feature. or a property. or something. I think we can define this however we want to. I would not agree that a document belongs to the parser. The parser creates a document, yes, but it should then hand ownership of the document to the caller (who may then choose any number of data structures to track documents). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
