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

[<juanrgonzaleza@xxxxxxxxxxxxxxxxxxxx>]

Rick Marshall said:
> from a brief survey of your blog on this matter i can only say that like
>  so many other "critics" of xml your comments are really only meaningful
>  if you ignore a significant part of the problem space xml is solving.
>
> having said that - a few more comments:
>
> it probably would have been better for css to be an xml vocabulary from
> the start - but it prohibits nested "tags" so i guess it was deemed
> unnecessary - and that's true for some other syntaxes.

Well, in his Thesis (2005) Håkon Wium Lie writtes:

<blockquote>
XML syntax

One common criticism of CSS is that it uses its own syntax rather than
being written in XML. By using the XML syntax, it is argued, it would be
easier to parse CSS and style sheets could be read and written by standard
XML tools. Indeed, the choice of syntax is an important one and if the
arguments for using the XML syntax, as stated above, are true, CSS could
have benefited from using XML. There are, however, several reasons why CSS
is not written in XML.

First, when CSS was developed, XML was not available. XML became a W3C
Recommendation in February 1998 [XML 1998], and switching syntax at that
point would have incurred a considerable cost. SGML, however, was
available, and some people argued that a SGML-based syntax should be used
[Gramlich 1996]:

    We do not know how other vendors feel, but we are getting tired of
having to implement a new parser every time something new comes out of
W3C (PICS, PEP, CSS, HTTP-NG, etc.) It is clear that CSS has lavished
a great deal of attention on coming up with an extremely textually
compact way of representing style sheets. Unfortunately, we have
little confidence that all vendors will properly implement the CSS
parser and this will lead to serious style sheet interoperability
problems. (If you do not agree, just think of how long it has taken to
get most web clients to parse the HTML subset of SGML reasonably
properly.) We have additional concerns about burdening the content
providers, with yet another syntax in order to express style sheets
in; SGML has a pretty awful syntax, but content providers have already
mastered the ability to generate it.

In the end, human read- and writability was valued higher than reusability
of parsers. The CSS syntax is optimized for writing style sheets, and it
is doubtful that there is an XML encoding system that is more friendly to
humans. Also, writing a CSS parser is relatively simple.

The most important benefit from writing CSS in XML would probably have
been an increased acceptance in the XML community.
</blockquote>

Well, being imprecise one can see XSL-FO as a XML version of CSS. XSL-FO
is very far from popular in the web.

> </> terminators (or "full stop syntax" as i like to think of it) are
> more readable in simple examples, but i can assure that in large machine
>  generated documents such as some of the edi stuff we do it would be
> incredibly unreadable. my own syntax for unibase (which does use a full
> stop syntax) can get very unreadable and difficult to debug on large
> programs. it's a shame html and/or xml weren't known at the time i
> designed the syntax.

I only can reply this in the way i did in the past.

XML: only <tag>content</tag>

LMNL: [tag}content{tag]  or  [tag}content{] **

ConciseXML: <tag>content</tag>  or  <tag>content</>

Use the full end tag for large content and the 'full stop syntax' for
short content. For instance, i think that anyone here -including XML fans-
would agree that XQueryX

<xqx:attributeName>year</xqx:attributeName>

is more readable as

<xqx:attributeName>year</>

specially with one may read many many lines

...
<xqx:returnClause>
  <xqx:elementConstructor>
    <xqx:tagName>book</xqx:tagName>
    <xqx:attributeList>
      <xqx:attributeConstructor>
        <xqx:attributeName>year</xqx:attributeName>
        <xqx:attributeValueExpr>
          <xqx:pathExpr>
            <xqx:stepExpr>
              <xqx:filterExpr>
                <xqx:varRef>
                  <xqx:name>b</xqx:name>
                </xqx:varRef>
              </xqx:filterExpr>
            </xqx:stepExpr>
          <xqx:stepExpr>
            <xqx:xpathAxis>attribute</xqx:xpathAxis>
            <xqx:nameTest>year</xqx:nameTest>
          </xqx:stepExpr>
        </xqx:pathExpr>
      </xqx:attributeValueExpr>
    </xqx:attributeConstructor>
...

> all of this would be a lot easier if every document was checked against
> a dtd or xsd - essential for our work and a whole other topic.
>
> rick
>


Juan R.

Center for CANONICAL |SCIENCE)