Re: SD1 - Short End Tags

len bullard wrote:
> 
> Arjun Ray wrote:
> >
> > On Fri, 16 May 1997, Dave Hollander wrote:
> >
> > > I am shocked; there have been no postings about this proposal.
> >
> > 8 months ago, I was one of the few who argued for empty end-tags. The ERB
> > decided otherwise.
> >
> > But I agree, the lack of posts on this proposal (even to heap scorn on
> > it:-)) is somewhat surprising.
> >
> > Arjun
> 
> Some decisions for simplicity were probably not simplifying.
> 
> The use of the empty end tag is well established in IDE/AS
> and used a lot when entering manually and converting.  Without
> pretty print indentions, it does make reading a little harder,
> and for someone doing simple macros based on search and
> replace, empty end tags are less than idea.  However, since
> the specification does not mandate them, having that option
> is attractive and one less thing to change in existing code.

There is one other argument for them.  In some SGML systems, 
object-likeness was achieved by using the GI as a post-processed 
object class identifier:

<!ELEMENT GeorgeISSonOfSam 

silly example but also not the point.  By using this orthogonal
processing, 
it was possible to create database effects.  Now, while this may 
be a less than ideal solution, that is also not the point.  The problem
was 
these extended GIs when required to have matching end tags 
raised the file size considerably.  It is a problem for any 
design that uses the GI as basis for a compound morphology.

Whether this issue is a priority one issue or not is a coin toss. 
For my money, it isn't a high priority but a nicety.  OTH, I'm 
used to it so maybe have a higher comfort level.

Some systems already do it, and others make it an option.  While 
the arguments for readability and desperate perl hackers are 
sympathetically met, the need for optionality seems clear in that 
IMO, it is the responsibility of the application designer to decide 
that an endtag must be *named*.  Only the application designer 
knows about the processes and consumers of the output of processes.  

len

Received on Friday, 16 May 1997 20:28:04 UTC