Rick Jelliffe said:
> I think Juan needs to look at goal # 10 for XML "Terseness is of minimal
>  importance"

I think that would be "Terseness is of minimal importance but when is not"

> and also the goal that there should be as few optional features as
> possible.

Well, i think that XML is very contrary to that goal.

- elements vs attributes

- DTD vs Schema vs other

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

- Multiple sintaxes for authoring

- DTD entities vs, PI entities, vs. Schema entities vs...

- XSL-FO vs CSS.

- HTML link vs. Xlinx vs. Hlink

- Etc.

Option for </> is of "minimal importance" in this landscape of options.

> SGML still exists (and is widely used in some traditional sectors
> (despite the hype)) and
> he can use that to get </>.

And is suitable for the web?

> XML was not created to be a perfect language
>  that would suit everyone.  It was designed to be SGML deliverable over
> the web. Of course if you have different goals you will generate a
> different language.

Therefore the X of XML does not mean eXtensible to suit user needs. When
XML was designed first time, people decided what would be in and what
would be out. I see no problem with review this again with an eye in
future XML.

> But its value comes from its being a standard.

Success in this world becomes from a sum of three main contributions:

1) technical points

2) Standarization

3) Marketing

XML benefits from the three. 2) without 1) is not succesful in the long
run and i think that XML is succesful, not in the original goal of "SGML
for the web" but like generic data format.

> Juan is correct that allowing </> has little effect on the complexity of
>  a parser, just as
> allowing comments, PIs, CDATA, different literal delimiters, numeric
> character references,
> the built-in character references, and empty tags don't require much to
> support. Compared to the complexity of supporting DTDs, entities,
> multiple character sets. But what about
> short-tags on start tags, attribute name omission, and tag-ommission? A
> line has to be drawn somewhere, and the argument against </> isnt
> complexity but readability. The fact that LMNL supports something says
> exactly nothing about what XML should support.

Sure! but one can extend that argument and the fact that XML 1 does not
support something says exactly nothing about what a XML 2 should support.

> As an example of an XML-size language that relaxes a lot of XML's rules
> and accepts more of SGML, see  ECS (Editor's Concrete Syntax) which is
> what Topologi's markup editor uses for SGML  editing.
>   http://www.topologi.com/resources/pdfs/ECS.pdf
>
> It accepts </> as well, and can be quite easily converted to XML. I am
> sure other people have similar little languages (though perhaps not
> grounded properly in the standard like ECS is.)

Thanks by the link but if i understood original message opening this
thread the point was to add extra funcionality to available XML. Since i
know a bit the (political?) difficulties to do that i has suggested
ConciseXML because has funcionality of XML and add extra stuff can be
_vital_ to some.

> Cheers
> Rick Jelliffe
>

Juan R.

Center for CANONICAL |SCIENCE)