Re: [xml-dev] Generic XML Tag Closer </> (GXTC)

[<juanrgonzaleza@canonicalscience.com>]

Liam Quin said:
> On Fri, Aug 18, 2006 at 04:31:34PM +0800, Melvin Chin wrote:
>> May I seek some opinions on this topic/proposal?
>>
>> To extend XML spec just a little to permit use of "</>" (GXTC)
>
> One of the reasons we took this out of XML (it was in SGML, of
> course) was that we knew from a decade (roughly) of implementation
> experience that there were some problems with it.
>
> The most common problem was people losking track of tags, and
> thinking they had closed something they hadn't.  Sometimes they
> would get an error and spend ages trying to fix it.  A program
> that filled in the close tags would (as they saw it) "do the
> wrong thing", and they'd even file bug reports, at SoftQuad we
> got bug reports about minimization on a regular basis even
> though the problem was always (OK, once someone found a real
> bug, so almost always) though it was the data that was faulty.

Well, nothing of this really justify do not leaving closing </>s as
*optional*. If it was to generate so many problems as claimed then nobody
would use them instead the full end tags, somewhat like the SVG DTD is
being not used. However, forcing the full end tag in the XML spec has a
well defined effect, _obligating_ to people to develop alternatives: e.g.
ConciseXML.

An posible appeal to the complexity of parser because of two types of end
tags may be not a real issue since also the LMNL language presented at
Extreme 2002 leaves the full end tag *optional* in annotations,

[tag}content{tag] vs. [tag}content{]

Somewhat as XML 1.0 has the (strange?) duality

<empty-tag></empty-tag> vs. <empty-tag/>

> When there was no error, the markup was incorrect.
>
> And sometimes the frustrated people trying to correct the error
> would just shove end tags in there until the thing parsed :-)
>
> With a LISP program,
>     (multiply (3 (add 4 7) 6))
> and
>     (multiply (3 (add 4 7 6)))
> are both syntacitcally valid, but when you run them you get different
> results.

This example is very interesting, since the W3C XML representation of
above LISP –i.e. MathML- is just so sintatically valid!

The rules are

( ==> <apply>
) ==> </apply>
multiply ==> <times/>
add ==> <plus/>
3 ==> <cn>3</cn>
4 ==> <cn>4</cn>
7 ==> <cn>7</cn>
6 ==> <cn>6</cn>

> With XML, people were marking up assertions about text, precisely
> because the computer couldn't do it.  You can't "run" a document
> to tell if a title has got an extra line of text in it by mistake, or
> that you've marked up an author's name as "Aerial Photography", to quote
> an example mentioned at Extreme Markup.  A human looks
> at the metadata and says, "this is poor quality", but the
> computer is perfecrly happy.

Often the end tag does not help in those issues and as recognized in the
IBM-developers article I cited in this thread, forcing end tags to authors
increase the possibility to type errors.

>
> The supposed benefit of minimisation -- and there are a host of
> other similar features -- is for people typing XML "by hand",
> e.g. on a card punch.  For automatically generated XMl there is
> no real benefit -- the extra few bytes help in debugging and
> robustness, and vanish when compression is used.

Let me repeat again ConciseXML people says about full end tags:

<blockquote>
Closing tagname is optional.
Not only does this remove unnecessary clutter, but when ConciseXML is used
as the syntax for dynamic languages, the tagname may not be known until
runtime, and therefore the closing tagname must be optional.
</blockquote>

I am unable to see how full end tags can help to debugging in every case.
When I am debugging a XSLT I rely on well-formatted code with indentation
and lot of whitespace whereas omiting the unrelevant noisy information of
end tags.

<xsl:template name="doSubstitutions">
  ...
  <xsl:choose>
    <xsl:when test="$index&gt;count($substitutions/sub-rule)">
      <xsl:value-of select="$input"/>
    />
    <xsl:otherwise>
      <xsl:variable ...
      ...
      <xsl:call-template name="doSubstitutions">
        <xsl:with-param name="input">
          <xsl:call-template name="substitute">
            <xsl:with-param name="input"       select="$input"/>
            <xsl:with-param name="target"      select="$target"/>
            <xsl:with-param name="replacement" select="$replacement"/>
          />
        />
        <xsl:with-param name="index" select="$index+1"/>
      />
    />
  />
/>

<xsl:template name="doSubstitutions">
  ...
/>

However, can understand opinions contrary to my owns.

About compression we could talk other day...

>
> Liam
>
> --
> Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
> http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/


Juan R.

Center for CANONICAL |SCIENCE)