- From: Alex Milowski <lex@www.copsol.com>
- Date: Fri, 6 Jun 1997 10:22:03 -0500 (CDT)
- To: w3c-sgml-wg@w3.org
> Deborah Aleyne Lapeyre wrote: > > > > Alex writes: Simplicity does not always equal functionality. > > > > May I second that. DTDs without parameter entities are MORE > > difficult, not less difficult, to write, to read, and > > ESPECIALLY to maintain. > > > > They are more difficult to parse. > > Umm... no functionality is lost without them. Some ease of > maintenance goes away. Unless you count ease of maintenance as functionality! ;-) > But since the majority appears to want them, and they aren't > hard to implement we are told, I've no objection to them > being there. I prefer fewer features because I think the > odds of a first season hit are better without the big show > number in the first act. Having implemented part of an SGML parser (while temporarily insane--I thought I didn't want to use SP) I can vouch for their ease of implementations. You have to put the storage management infrastructure in for general entities, hence, you are most of the way there. This issue seems to come down more on the philosophical side of what parameter entities are trying to accomplish. We all probably agree that we know enough to design something that works better but what that something is we all have different ideas. I think it would be a good idea to get a list of re-use/module/namespace issues that we are trying to solve and work from there. This is probably an aside to the current task at hand. I'm willing to help coordinate such an effort if this is not within the current tasks of the ERB. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608
Received on Friday, 6 June 1997 11:23:51 UTC