Re: SD1 - Short End Tags [fmt]

I am highly supporting the proposal of Short End Tags.


> ----------
> Von: 	altheim[SMTP:altheim@mehitabel.Eng.Sun.COM]
> Gesendet: 	Samstag, 17. Mai 1997 00:42
> An: 	w3c-sgml-wg@w3.org
> Betreff: 	Re: SD1 - Short End Tags [fmt]
> 
> 
> Where a simple processor could simply search forward for the end tag,
> this
> would no longer be the case. We now need to build a parse tree. I'm
> sure that
> Microsoft's (or any large vendor's) application design would have no
> problems dealing with this, but our college programmer's project just
> got a lot more complex, and that little perl script just got a *lot*
> bigger.
> 
In order to safely parse a well formed XML-Instance (who´s GIs still
must be balanced) it 
is required to keep the GI of the actual open elements. Therefore, a
simple search for the
endtag would not fulfil the requirements of an XML-parser.

Anyhow, if one wants to look for the matching endtag, it is simply a
counter reflecting the
actual number of open elements. I don´t think its too difficult. 

> And documents got a lot harder to read. For what? Some savings in disk
> space? 2GB drives come cheap nowadays, and the difference in file
> sizes
> at 28.8K would hardly be noticed. We're not transferring 15MB
> databases
> of predominantly markup, are we? 
> 
We are dealing with engineering data to be published actually as SGML in
the intranet
(XML in the future) where we have 100000 and more Elements. We found out
that we save 40% of 
instance size by simply using Short End Tags. This is not only a matter
of diskspace but
also network bandwidth.
>  
> >  Proposal: For readability and convenience when dealing with
> database
> >  records, the element name within an end tag is optional. That is,
> >  </NAME> is same as </>.
> 
> This seems somewhat Orwellian. For "readability and convenience", the
> XML spec
> has made end tag GIs *required*. You're turning that idea upside-down.
> 
You are right, but diffenerent situations might cause different views

> This proposal also diminishes its own impact by showing short end tags
> only applied to leaf nodes. Let's be more realistic. It gets a whole
> lot
> more complicated and difficult to parse if this proposal is accepted
> as
> stated, which allows short end tags everywhere. A typical example from
> my desk:
> 
The Example above was from my desk ;-)

> We also pay a very high price in losing the simplicity of matching
> start and end tags, particularly for the grassroots-type application
> 
Í do not believe that the price is very high.

> and content developers. CGI and perl script writers dealing with
> transactions now would have to keep track of level, and humans would
> probably just give up after about three or four levels. Heck, that's
> the
> reason I don't like chess.
> 
To be honest, who will deals with the raw XML files? Take an XML-editor
who inserts GIs in endtags.
Write a simple tool that does this. Use SPAM ...

> Is this really worth all the headache?
> 
yes


Regards/Mit freundlichen Gruessen
========================================================================
======
Bernhard Weichel              Phone:  (49) 711 811 8322
Robert Bosch GmbH               Fax:  (49) 711 811 8262
Dept. K3/EES4                 eMail:  bernhard.weichel@pcm.bosch.de
P.O. Box 30 02 40                     
D-70442 Stuttgart
Germany