Re: SD1 - Short End Tags [fmt]

Paul Grosso wrote:
> 
> At 16:58 1997 05 17 +0900, Weichel Bernhard (K3/EES4) wrote:
> >I am highly supporting the proposal of Short End Tags.
> >
> "Safe" parsing is not relevant except for
> applications that are expected to be able to handle erroneous documents,
> but the whole point is that most XML processors [in fact, all XML
> processors according to the draconian error handling stance] can assume
> correct input and so don't have to tiptoe around to be "safe."

When given a choice between obeying the draconian parse rule and 
bringing down the size of the database, the application developer will 
ignore the draconian parse.  Old rules:  make it run, make it run
faster.

OTH, the use of XML with even minimized end tags would be
straightforward 
for database transfers (consider upsizing - eg, FoxPro to Oracle)
although 
not complete for that application (validation rules). This isn't a 
PERL hacker app.  Who is being penalized?  The Perl hacker (nice but 
no money) or the professional database application developer (skilled 
and produces apps worth lots of money).  Easy choice for companies that 
have a business model which says "sell a million units or don't even 
consider developing it".  
 
> Sure, it's easy for a parser to insert GIs in endtags.  But XML is
> supposed to be easy for the lightest weight of applications.  Why
> should the perl script be forced to be prefaced by a SPAM application?

A perl hacker is responsible for knowing the rules of the schemata 
as is anyone trying to use a database.  If they are not using a
database,  
then the application designer should insist on non-minimized full end
tags 
because it makes sense for that application.

What we have here is a real world application designer expressing a 
real world application requirement for a very profitable application 
that can currently only be built with SGML.
 
> I'd turn it around and say if space/transfer volume savings is so
> important, use short tag names and compression schemes.  Compression
> and decompression are much simplier, smaller, and more ubiquitous
> applications than XML-parsing, GI-inserting applications.

Or use the rule of thumb that was applied several times in 
several arguments in the first phase of XML design:  

"don't like it? use SGML".  

I'd say that applies to this request.  The 
alternative is to give the application designer what they 
say they need if they need to use XML.

len bullard
intergraph corporation

Received on Tuesday, 20 May 1997 19:11:29 UTC