May I seek some opinions on this topic/proposal?
To extend XML spec just a little to permit use of "</>" (GXTC)
to be placed wherever it is permitted in the current XML spec
to place a closing tag. The semantics will be to effect a
closing of the nearest open tag before the position of GXTC.
Any opinion is fine, useful, crazy, nonsense, should be done,
must not coz it's going to break many things
I could see some good use of it, but do note the deep potential
impact it may bring. Would like to hear from you.
Thanks.
cheers,
mc
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>
The list archives are at
To subscribe or unsubscribe from this list use the subscription
manager: <>

Melvin Chin said:
May I seek some opinions on this topic/proposal?

To
extend XML spec just a little to permit use of "</>" (GXTC)
to be placed wherever it is permitted in the current XML spec
to place a closing tag. The semantics will be to effect a
closing of the nearest open tag before the position of GXTC.

Any opinion is fine, useful, crazy, nonsense, should be done,
must not coz it's going to break many things

I could see some good use of it, but do note the deep potential
impact it may bring. Would like to hear from you.

Thanks.

cheers,
mc

I agree with Michael Kay about the fiasco of XML 1.1.

If you need that kind of extensions then look to alternative approaches.
E.g. ConciseXML [http://www.concisexml.org/] permits the use of generic
end tag.

XML 1.0: <textarea>hi</textarea>

ConciseXML: <textarea>hi</>

Juan R.

Center for CANNICAL |SCIENCE)

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>

The list archives are at

To subscribe or unsubscribe from this list use the subscription
manager: <>

Melvin Chin wrote:
May I seek some opinions on this topic/proposal?

To extend XML spec just a little to permit use of "</>" (GXTC)
to be placed wherever it is permitted in the current XML spec
to place a closing tag. The semantics will be to effect a
closing of the nearest open tag before the position of GXTC.

wondering what benefit to this other then some syntatic human orientated
sugar ?

u know extending the XML spec to do this would have a pretty serious
impact on other things such as XSLT, XPATH, etcso its highly unlikely!

as a sidenote: have you checked out http://www.lmnl.net, its a good
example of taking what is existing and achieving something useful.

gl, Jim Fuller

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>

The list archives are at

To subscribe or unsubscribe from this list use the subscription
manager: <>

James Fuller said:
Melvin Chin wrote:
>May I seek some opinions on this topic/proposal?
>>
>To
>extend XML spec just a little to permit use of "</>" (GXTC)
>to be placed wherever it is permitted in the current XML spec
>to place a closing tag. The semantics will be to effect a
>closing of the nearest open tag before the position of GXTC.
>
>
wondering what benefit to this other then some syntatic human orientated
sugar ?

There are several advantages. In my previous message i cited
[http://www.concisexml.org/]

<blockquote>
5. 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>

as a sidenote: have you checked out http://www.lmnl.net, its a good
example of taking what is existing and achieving something useful.

gl, Jim Fuller

Hum, liminal presents serious theoretical difficulties with the range
calculus doing very difficult can be a satisfactory extension of XML.

[]

In fact, liminal is apparently a 'dead horse' (liminal was first presented
at 2002!).

However, i obtained very good ideas from liminal as the generalized
attribute model and the increase on difference between start and end tags
for improving readability. However i follow an alternative approach to
dealing with non-hierarchies because overlap generates many headaches.

Note that end tags are also optional in liminal _annotations_. End tags
are required in ranges because of ambiguity in non-hierarchical ranges.

In short,

XML 1.0: <textarea>hi</textarea>

liminal: [textarea}hi{] or [textarea}hi{textarea]

ConciseXML: <textarea>hi</or <textarea>hi</textarea>

SXML: (textarea "hi")

CanonML (both versions markup and environments): [::textarea hi]

Juan R.

Center for CANNICAL |SCIENCE)

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>

The list archives are at

To subscribe or unsubscribe from this list use the subscription
manager: <>

juanrgonzaleza (AT) canonicalscience (DOT) com wrote:
James Fuller said:

>>Melvin Chin wrote:

There are several advantages. In my previous message i cited
[http://www.concisexml.org/]

<blockquote>
5. 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>

w/o sounding too argumentative, 'removing unnec clutter' is not solved
by thisputting in an something like </this will confuse a number of
users.

If the goal is to make representation shorter or more readable then
there are some basic style conventions that can improve things in XML.

IMH, if we are considering changes to XML spec to achieve something
more readable there are other things that should happen before tinkering
with lexical representation changes.

Hum, liminal presents serious theoretical difficulties with the range
calculus doing very difficult can be a satisfactory extension of XML.

[]

In fact, liminal is apparently a 'dead horse' (liminal was first presented
at 2002!).

I would argue that there is a 'long tail' effect with lots of xml
related technologypeople will use when they need towe dont need to
wait for mass adoption if you have a particular requirement.

I have considered using lmnl many times, though was always able to
educate the end user just enough to use an editor/web interface.

However, i obtained very good ideas from liminal as the generalized
attribute model and the increase on difference between start and end tags
for improving readability. However i follow an alternative approach to
dealing with non-hierarchies because overlap generates many headaches.

Note that end tags are also optional in liminal _annotations_. End tags
are required in ranges because of ambiguity in non-hierarchical ranges.

In short,

XML 1.0: <textarea>hi</textarea>

liminal: [textarea}hi{] or [textarea}hi{textarea]

ConciseXML: <textarea>hi</or <textarea>hi</textarea>

SXML: (textarea "hi")

CanonML (both versions markup and environments): [::textarea hi]

apologies for my selfishness; I am interested in the impact of change of
lexical representation downstreamnot necc in the lexical
representation itself (we would then have lots of worm cans with
permathread on them to go through).

cheers, Jim Fuller

James Fuller said:
juanrgonzaleza (AT) canonicalscience (DOT) com wrote:
>James Fuller said:
>>
Melvin Chin wrote:
>>
>There are several advantages. In my previous message i cited
>[http://www.concisexml.org/]
>>
><blockquote>
>5. 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>
>
w/o sounding too argumentative, 'removing unnec clutter' is not solved
by thisputting in an something like </this will confuse a number of
users.

If the goal is to make representation shorter or more readable then
there are some basic style conventions that can improve things in XML.

I think that is not that worried to ConciseXML people when decided to
leave naming the end tags optional, unless i was reading too beyond the
"tagname may not be known until runtime"

IMH, if we are considering changes to XML spec to achieve something
more readable there are other things that should happen before tinkering
with lexical representation changes.

I think i was not considering changes in my initial reply to Melvin Chin.

If he needs end </i recommended to him the use of ConciseXML instead
waiting for a modification of W3C XML that i) i doubt will be promoted ii)
even when accepted and the spec ready, it will take years before all was
working in real life.

we dont need to
wait for mass adoption if you have a particular requirement.

Therein my advice to Melvin Chin to use ConciseXML if he needs the </>
option.

cheers, Jim Fuller

Juan R.

Center for CANNICAL |SCIENCE)

my 2 cents

With the availability of relatively low cost or free XML editors having
good content completion, I see no advantage even from the standpoint of
data entry. Just for instance, with oXygen's content completion will
close tags with about three ( < / {ENTER} ) keystrokes.

</makes the closure of an element anonymous. To the human reader, a
long span of content in which the start tag is no longer near the
anonymous end tag makes a visual scan useless.

When a (start|end) tag is missing the anonymous end tag makes it harder
to distinguish which element is incorrect. This might not mean as much
when using a tree editor, but when using a source mode editor or
text-based script (print/puts/echo) to generate content, or plain old
damaged files, you're likely to loose more time trying to debug. For
that matter, if I textually cut-and-paste a fragment with an XML end tag
so that its position is swapped outside of an ancestor element
structure's end tag, the validation process is likely to give errors; if
I textually cut-and-paste the same as an anonymous end tag, the
validation process may not know anything is wrong at all if the end tags
still match in number. This can happen for instance when you select a
line of content but you don't notice that the end tag got selected too,
and you drag and drop.

Melvin Chin wrote:
May I seek some opinions on this topic/proposal?

To extend XML spec just a little to permit use of "</>" (GXTC)
to be placed wherever it is permitted in the current XML spec
to place a closing tag. The semantics will be to effect a
closing of the nearest open tag before the position of GXTC.

Any opinion is fine, useful, crazy, nonsense, should be done,
must not coz it's going to break many things

I could see some good use of it, but do note the deep potential
impact it may bring. Would like to hear from you.

Thanks.

cheers,
mc
--

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of ASIS <http://www.oasis-open.org>

The list archives are at

To subscribe or unsubscribe from this list use the subscription
manager: <>
--

Mitch Amiano said:
my 2 cents

With the availability of relatively low cost or free XML editors having
good content completion, I see no advantage even from the standpoint of
data entry. Just for instance, with oXygen's content completion will
close tags with about three ( < / {ENTER} ) keystrokes.

Please read previous comments and follow the link to ConciseXML in this
thread. They are not so worried about editing when leaving the </>
_optional_. They are more worried about limitations of end tags in
dinamical environments.

There exist also problems with end tags in large datuments. That is the
reason that XSLT includes parsing capabilites for string data because when
encoding large quantity of data XML end tags (and even start tags!) are
very inefficient (this is discussed by Jenny Tennison in her book

[]).

Inefficiency is also reason for SVG paths d="M "

</makes the closure of an element anonymous. To the human reader, a
long span of content in which the start tag is no longer near the
anonymous end tag makes a visual scan useless.

Not sure. Since this point is common to XML, SGML, ConciseXML, liminal,
CanonML, and SXML, let me use next example for discussion

[]:

<breakfast-menu>
<food>
<name>Belgian Waffles</name>
<price>$5.95</price>
<description>two of our famous Belgian Waffles with plenty of real
maple syrup</description>
<calories>650</calories>
</food>

<food>
<name>Strawberry Belgian Waffles</name>
<price>$7.95</price>
<description>light Belgian waffles covered with strawberrys and
whipped cream</description>
<calories>900</calories>
</food>

<food>
<name>Berry-Berry Belgian Waffles</name>
<price>$8.95</price>
<description>light Belgian waffles covered with an assortment of fresh
berries and whipped cream</description>
<calories>900</calories>
</food>

<food>
<name>French Toast</name>
<price>$4.50</price>
<description>thick slices made from our homemade sourdough
bread</description>
<calories>600</calories>
</food>

<food>
<name>Homestyle Breakfast</name>
<price>$6.95</price>
<description>two eggs, bacon or sausage, toast, and our ever-popular
hash browns</description>
<calories>950</calories>
</food>
</breakfast-menu>

SGML (when option of avoiding some end tags is available):

<breakfast-menu>
<food>
<name>Belgian Waffles
<price>$5.95
<description>two of our famous Belgian Waffles with plenty of real
maple syrup
<calories>650
</food>

<food>
<name>Strawberry Belgian Waffles
<price>$7.95
<description>light Belgian waffles covered with strawberrys and
whipped cream
<calories>900
</food>

<food>
<name>Berry-Berry Belgian Waffles
<price>$8.95
<description>light Belgian waffles covered with an assortment of fresh
berries and whipped cream
<calories>900
</food>

<food>
<name>French Toast
<price>$4.50
<description>thick slices made from our homemade sourdough bread
<calories>600
</food>

<food>
<name>Homestyle Breakfast
<price>$6.95
<description>two eggs, bacon or sausage, toast, and our ever-popular
hash browns
<calories>950
</food>
</breakfast-menu>

ConciseXML (if the _option_ of </is mixed with full end tags)

<breakfast-menu>
<food>
<name>Belgian Waffles</>
<price>$5.95</>
<description>two of our famous Belgian Waffles with plenty of real
maple syrup</>
<calories>650</>
</food>

<food>
<name>Strawberry Belgian Waffles</>
<price>$7.95</>
<description>light Belgian waffles covered with strawberrys and
whipped cream</>
<calories>900</>
</food>

<food>
<name>Berry-Berry Belgian Waffles</>
<price>$8.95</>
<description>light Belgian waffles covered with an assortment of fresh
berries and whipped cream</>
<calories>900</>
</food>

<food>
<name>French Toast</>
<price>$4.50</>
<description>thick slices made from our homemade sourdough bread</>
<calories>600</>
</food>

<food>
<name>Homestyle Breakfast</>
<price>$6.95</>
<description>two eggs, bacon or sausage, toast, and our ever-popular
hash browns</>
<calories>950</>
</food>
</breakfast-menu>

liminal (full end tags are needed for overlaping ranges. end tags
are _only_ available for annotations because cannot overlap):

[breakfast-menu}
[food}
[name}Belgian Waffles{name]
[price}$5.95{price]
[description}two of our famous Belgian Waffles with plenty of real
maple syrup{description]
[calories}650{calories]
{food]

[food}
[name}Strawberry Belgian Waffles{name]
[price}$7.95{price]
[description}light Belgian waffles covered with strawberrys and
whipped cream{description]
[calories}900{calories]
{food]

[food}
[name}Berry-Berry Belgian Waffles{name]
[price}$8.95{price]
[description}light Belgian waffles covered with an assortment of fresh
berries and whipped cream{description]
[calories}900{calories]
{food]

[food}
[name}French Toast{name]
[price}$4.50{price]
[description}thick slices made from our homemade sourdough
bread{description]
[calories}600{calories]
{food]

[food}
[name}Homestyle Breakfast{name]
[price}$6.95{price]
[description}two eggs, bacon or sausage, toast, and our ever-popular
hash browns{description]
[calories}950{calories]
{food]
{breakfast-menu]

CanonML (does not use end tags but can add comments in end ] if you desire):

[::breakfast-menu
[::food
[::name Belgian Waffles]
[::price $5.95]
[::description two of our famous Belgian Waffles with plenty of real
maple syrup]
[::calories 650]]

[::food
[::name Strawberry Belgian Waffles]
[::price $7.95]
[::description light Belgian waffles covered with strawberrys and
whipped cream]
[::calories 900]]

[::food
[::name Berry-Berry Belgian Waffles]
[::price $8.95]
[::description light Belgian waffles covered with an assortment of
fresh berries and whipped cream]
[::calories 900]]

[::food
[::name French Toast]
[::price $4.50]
[::description thick slices made from our homemade sourdough bread]
[::calories 600]]

[::food
[::name Homestyle Breakfast]
[::price $6.95]
[::description two eggs, bacon or sausage, toast, and our
ever-popular hash browns]
[::calories 950]]
]

SXML:

(breakfast-menu
(food
(name "Belgian Waffles")
(price "$5.95")
(description "two of our famous Belgian Waffles with plenty of real
maple syrup")
(calories "650"))

(food
(name "Strawberry Belgian Waffles")
(price "7.95")
(description "light Belgian waffles covered with strawberrys and
whipped cream")
(calories "900"))

(food
(name "Berry-Berry Belgian Waffles")
(price "$8.95")
(description "light Belgian waffles covered with an assortment of
fresh berries and whipped cream")
(calories "900"))

(food
(name "French Toast")
(price "$4.50")
(description "thick slices made from our homemade sourdough bread")
(calories "600"))

(food
(name "Homestyle Breakfast")
(price "$6.95")
(description "two eggs, bacon or sausage, toast, and our ever-popular
hash browns")
(calories "950"))
)

Many people do not find greater readability with the XML format. , of
course, disagree. Morever, the supposed readability of end tags often
disappears when using attributes since end tags can match any start tag
independently of attributes:

<section class="normal">
<section class="special">

</section>
</section>

What section closes the final tag? first? second? other contain in ?

When a (start|end) tag is missing the anonymous end tag makes it harder
to distinguish which element is incorrect. This might not mean as much
when using a tree editor, but when using a source mode editor or
text-based script (print/puts/echo) to generate content, or plain old
damaged files, you're likely to loose more time trying to debug. For
that matter, if I textually cut-and-paste a fragment with an XML end tag
so that its position is swapped outside of an ancestor element
structure's end tag, the validation process is likely to give errors; if
I textually cut-and-paste the same as an anonymous end tag, the
validation process may not know anything is wrong at all if the end tags
still match in number. This can happen for instance when you select a
line of content but you don't notice that the end tag got selected too,
and you drag and drop.

There are situations where XML syntax can offer us advantages and
situations where cannot. E.g. use namespaces; what is more readable and
understandable, the standard XML

<math xmlns:mml="">
<mml:apply>
<mml:eq/>
<mml:ci>E</mml:ci>
<mml:apply>
<mml:times/>
<mml:ci>m</mml:ci>
<mml:apply>
<mml:power/>
<mml:ci>c</mml:ci>
<mml:cn>2</mml:cn>
</mml:apply>
</mml:apply>
</mml:apply>
</math>

or next (maybe a proposal for next MathML 3 input syntax)?

[math @xmlns:mml=""
[mml:apply
[mml:eq]
[mml:ci E]
[mml:apply
[mml:times]
[mml:ci m]
[mml:apply
[mml:power]
[mml:ci c]
[mml:cn 2]
]
]
]
]

Note you can know _exactly_ what each ] is closing even without a syntax
highlight editor (there are many for free). For instance, i want know what
closes the third ] begining from the end. Then i put cursor in it *] and
next move it up and automatically i finalize in *[math:apply the second
apply element. do not need count brackets not visual matching them
(the theoretical advantage of XML end tags vanishes here). With a sintax
highlighter editor it is better still since you can do

[math @xmlns:mml=""
[mml:apply
[mml:eq]
[mml:ci E]
[mml:apply
[mml:times]
[mml:ci m]
[mml:apply
[mml:power]
[mml:ci c]
[mml:cn 2] ]]]]

and selecting any "]" or "[" the editor highlihts the corresponding pair
for you.

cannot claim that XML syntax is best or more readable than other
syntax including the </notation in absolute terms. It is a case by case
methodology.

In
[]

I wrote some basic arguments against claims by Paul Prescod that XML
syntax is more robust in the face of errors. See also

[]

Juan R.

Center for CANNICAL |SCIENCE)

juanrgonzaleza (AT) canonicalscience (DOT) com wrote:
Mitch Amiano said:

>my 2 cents
>>
>With the availability of relatively low cost or free XML editors having
>good content completion, I see no advantage even from the standpoint of
>data entry. Just for instance, with oXygen's content completion will
>close tags with about three ( < / {ENTER} ) keystrokes.
>
>
Please read previous comments and follow the link to ConciseXML in this
thread. They are not so worried about editing when leaving the </>
_optional_. They are more worried about limitations of end tags in
dinamical environments.

What I responded to was not your supposed requirements but Melvin's
post, with my own suppositions of what might have motivated him to ask:

Any opinion is fine, useful, crazy, nonsense, should be done,
must not coz it's going to break many things
I don't see ConciseXML mentioned by Melvin. I have no problem with you
airing your views or advocating ConciseXML, but neither do I feel
limited to responding to you as if you were the original poster.

There exist also problems with end tags in large datuments. That is the
reason that XSLT includes parsing capabilites for string data because when
encoding large quantity of data XML end tags (and even start tags!) are
very inefficient (this is discussed by Jenny Tennison in her book

[]).

I'm familiar with trade-offs of choosing one storage and transmission
format above another. I chose to comment on an aspect of keying in the
data that the original poster might view as responsive to his question.
Inefficiency is also reason for SVG paths d="M "


></makes the closure of an element anonymous. To the human reader, a
>long span of content in which the start tag is no longer near the
>anonymous end tag makes a visual scan useless.
>
>
Not sure. Since this point is common to XML, SGML, ConciseXML, liminal,
CanonML, and SXML, let me use next example for discussion

I'll extend the example in a manner which hopefully illustrates my point
better, with a bit of well formed HTML gleaned from an old DSSSL-List post:

<HTML><BDY STYLE="font-family:helvetica,sans
sherif;font-size:12pt;background-color:#EEEEEE">
<DIV STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weight:bold;color:white">Belgian Waffles</-
$5.95</><DIV
STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">two of our famous
Belgian waffles with plenty of real maple syrup
<SPAN STYLE="font-style:italic">(650 calories per serving)</></>
<DIV
STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weigh
t:bold;color:white">Strawberry Belgian Waffles</- >$7.95 </<DIV
STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">light Belgian
waffles covered with strawberries and whipped cream<SPAN
STYLE="font-style:italic">(900 calories per serving)</></>
<DIV STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weight:bold;color:white">Berry-Berry Belgian Waffles</-
$8.95</><DIV
STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">light Belgian
waffles covered with an assortment of fresh berries and whipped cream<SPAN
STYLE="font-style:italic">(900 calories per serving)</>
<DIV STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weight:bold;color:white">French Toast</- $4.50</>
<DIV STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">thick slices
made from our homemade sourdough bread<SPAN STYLE="font-style:italic">(950
calories per serving)</></></>
<DIV STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weight:bold;color:white">Homestyle Breakfast</-
$6.95</><DIV
STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">two eggs, bacon
or sausage, toast, and our ever-popular hash browns</></></>

Now if I cut-and-paste wrong, which <DIVor <SPANwas supposed to be
terminated?
I can figure it out the sample is small but as it grows in
complexity and size I'd rather not have to guess.

(snip!)

Many people do not find greater readability with the XML format. , of
course, disagree. Morever, the supposed readability of end tags often
disappears when using attributes since end tags can match any start tag
independently of attributes:

<section class="normal">
<section class="special">

</section>
</section>

What section closes the final tag? first? second? other contain in ?

You're right, it is arguable, and probably not worth expending much
energy on.
I certainly wouldn't always argue that an XML format is the end-all and
be-all of formats I prefer writing RelaxNG's compact format to the
XML syntax.

In this case, at least I only have to scan for <sections>, not every
single element type in the document.
If it isn't well-formed, I'm going to have to weed out the
inconsistency, but the existence of the two </sectionend tags at least
tells me that it isn't the number of <sectionend tags that is the
problem. Especially where the element structures and namespaces get more
varied, I think I'd prefer not to do without that feature.
>When a (start|end) tag is missing the anonymous end tag makes it harder
>to distinguish which element is incorrect. This might not mean as much
>when using a tree editor, but when using a source mode editor or
>text-based script (print/puts/echo) to generate content, or plain old
>damaged files, you're likely to loose more time trying to debug. For
>that matter, if I textually cut-and-paste a fragment with an XML end tag
>so that its position is swapped outside of an ancestor element
>structure's end tag, the validation process is likely to give errors; if
>I textually cut-and-paste the same as an anonymous end tag, the
>validation process may not know anything is wrong at all if the end tags
>still match in number. This can happen for instance when you select a
>line of content but you don't notice that the end tag got selected too,
>and you drag and drop.
>
>
There are situations where XML syntax can offer us advantages and
situations where cannot. E.g. use namespaces; what is more readable and
understandable, the standard XML

<math xmlns:mml="">
<mml:apply>
<mml:eq/>
<mml:ci>E</mml:ci>
<mml:apply>
<mml:times/>
<mml:ci>m</mml:ci>
<mml:apply>
<mml:power/>
<mml:ci>c</mml:ci>
<mml:cn>2</mml:cn>
</mml:apply>
</mml:apply>
</mml:apply>
</math>

or next (maybe a proposal for next MathML 3 input syntax)?

[math @xmlns:mml=""
[mml:apply
[mml:eq]
[mml:ci E]
[mml:apply
[mml:times]
[mml:ci m]
[mml:apply
[mml:power]
[mml:ci c]
[mml:cn 2]
]
]
]
]

Note you can know _exactly_ what each ] is closing even without a syntax
highlight editor (there are many for free). For instance, i want know what
closes the third ] begining from the end. Then i put cursor in it *] and
next move it up and automatically i finalize in *[math:apply the second
apply element. do not need count brackets not visual matching them
(the theoretical advantage of XML end tags vanishes here). With a sintax
highlighter editor it is better still since you can do

[math @xmlns:mml=""
[mml:apply
[mml:eq]
[mml:ci E]
[mml:apply
[mml:times]
[mml:ci m]
[mml:apply
[mml:power]
[mml:ci c]
[mml:cn 2] ]]]]

and selecting any "]" or "[" the editor highlihts the corresponding pair
for you.

cannot claim that XML syntax is best or more readable than other
syntax including the </notation in absolute terms. It is a case by case
methodology.

In
[]

I wrote some basic arguments against claims by Paul Prescod that XML
syntax is more robust in the face of errors. See also

[]

No doubt an interesting article and conversation. I'll go look.

Regards
- Mitch

Juan R.

Center for CANNICAL |SCIENCE)
>
>
>
>

Thank you all very much for the valuable remarks and reminders
on pros and cons about GXTC. In particular, thanks to
Michael, Juan, Elliotte, James, David, Mitch, Florent, Tatu
(hope I didn't miss out on any) for the spirited discussions.

I'm going to look through ConciseXML a bit more. Not trying
to change the world here, but just trying to solve some
technical requirements which, ironically, were generated due
to lots of use of XML. The "optional" part of ConciseXML
which Juan pointed out appears to allow local tweakings while
maintaining compatibility with mainstream XML (at least on
the end tag specification). That sounds like music!

cheers,
mc

Mitch Amiano said:

I'll extend the example in a manner which hopefully illustrates my point
better, with a bit of well formed HTML gleaned from an old DSSSL-List
post:

<HTML><BDY STYLE="font-family:helvetica,sans
sherif;font-size:12pt;background-color:#EEEEEE">
<DIV STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weight:bold;color:white">Belgian Waffles</-
$5.95</><DIV
STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">two of our
famous Belgian waffles with plenty of real maple syrup
<SPAN STYLE="font-style:italic">(650 calories per serving)</></>
<DIV
STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weigh
t:bold;color:white">Strawberry Belgian Waffles</- >$7.95 </<DIV
STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">light Belgian
waffles covered with strawberries and whipped cream<SPAN
STYLE="font-style:italic">(900 calories per serving)</></>
<DIV STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weight:bold;color:white">Berry-Berry Belgian Waffles</-
$8.95</><DIV
STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">light Belgian
waffles covered with an assortment of fresh berries and whipped
cream<SPAN STYLE="font-style:italic">(900 calories per serving)</>
<DIV STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weight:bold;color:white">French Toast</- $4.50</>
<DIV STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">thick
slices made from our homemade sourdough bread<SPAN
STYLE="font-style:italic">(950 calories per serving)</></></>
<DIV STYLE="background-color:teal;color:white;padding:4px"><SPAN
STYLE="font-weight:bold;color:white">Homestyle Breakfast</-
$6.95</><DIV
STYLE="margin-left:20px;margin-bottom:1em;font-size:10pt;">two eggs,
bacon or sausage, toast, and our ever-popular hash browns</></></>

Now if I cut-and-paste wrong, which <DIVor <SPANwas supposed to be
terminated?
I can figure it out the sample is small but as it grows in
complexity and size I'd rather not have to guess.

Yes, in that case the end tag is helpful.

Three points: i) XML requires the end tag but other approaches leave it
optional, therefore, in ConciseXML you can write the full </SPANand
</DIVii) When codes are ordered and indented, you can easily match end
start tags even </iii) Special XML editors to assistance in editing of
XML docs can be used for matching XML fragments. I do not know if there
exists special editors for ConciseXML.

>>
>Many people do not find greater readability with the XML format.
>, of course, disagree. Morever, the supposed readability of end
>tags often disappears when using attributes since end tags can match
>any start tag independently of attributes:
>>
><section class="normal">
><section class="special">
>
></section>
></section>
>>
>What section closes the final tag? first? second? other contain in
>?
>>
>>
You're right, it is arguable, and probably not worth expending much
energy on.
I certainly wouldn't always argue that an XML format is the end-all and
be-all of formats I prefer writing RelaxNG's compact format to the
XML syntax.

In this case, at least I only have to scan for <sections>, not every
single element type in the document.

All depend of the structure of the doc. If the doc is full of section
elements, then scan for <sectionsonly does not help much.

If it isn't well-formed, I'm going to have to weed out the
inconsistency, but the existence of the two </sectionend tags at least
tells me that it isn't the number of <sectionend tags that is the
problem. Especially where the element structures and namespaces get more
varied, I think I'd prefer not to do without that feature.

Note i said:

>What section closes the final tag? first? second? other contain in
>?

Take a 1000 elements doc. You cannot know if exists a third section tag in
the ""

About inconsistency. We are asuming absence of end tag. I remember my
writting a MathML XML doc by hand (not being masoschistic that day but
because needing advanced features not supported by current tools: fine
parallel markup with M extensions) and i did mistake of writting <mi>
instead </mi>. Browser parser pointed to wrong localization when
validating. I did need some time before find the error in a non-automated
scan, then i was masochistic ;-)

Regards
- Mitch

Juan R.

Center for CANNICAL |SCIENCE)

Melvin Chin wrote:
May I seek some opinions on this topic/proposal?

To extend XML spec just a little to permit use of "</>" (GXTC)
to be placed wherever it is permitted in the current XML spec
to place a closing tag. The semantics will be to effect a
closing of the nearest open tag before the position of GXTC.

I released some C utilities to do this in 1999

The source code is gone now (anyone have a copy?), but they are trivial
to write.

Another approach is to use the open source SP parser, which is
cross-platform and distributed in most Linux distributions (IIRC) and do
that. It includes a tool to generate XML.

In SGML it is called short-tag minimization (as distinct from end-tag
omission). You will probably have to adjust the SGML declaration (syntax
configuration file) as appropriate.

You may find it easier to write your own little stack tracing tool to
pre-process the semi-XML coming in. If you are doing this as an internal
matter (i.e. as a stage in production) then ignore anyone who says "but
it is not standard": how you organize your internal processes is your
business, and in any case, it probably is standard (i.e., IS IS 8879 as
amended). If you are doing this and you are going to publish or on-send
the data, don't do it.

Cheers
Rick Jelliffe

* I wrote a little C program to do this

juanrgonzaleza (AT) canonicalscience (DOT) com wrote:
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.

I think Juan needs to look at goal # 10 for XML "Terseness is of minimal
importance"
and also the goal that there should be as few optional features as possible.

SGML still exists (and is widely used in some traditional sectors
(despite the hype)) and
he can use that to get </>. XML was not created to be a perfect language
that would suit everyone. It was designed to be SGML deliverable over
the web. course if you have different goals you will generate a
different language.

Any idiot can make up a better markup language than XML, and many idiots
in fact do so.
But its value comes from its being a standard.
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,

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.

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.

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.)

Cheers
Rick Jelliffe

Wed, 2006-08-23 at 16:02 +1000, Rick Jelliffe wrote:

Any idiot can make up a better markup language than XML, and many idiots
in fact do so.

I think this is a very condescending statement about the people like
David Megginson who put XML together. Saying that it only takes an idiot
to do better. You obviously have no understanding of the skills,
hardships, determination and sacrifices of any person who tries to
advance the common knowledge.

To illustrate, recently I visited Turkey and was shown a place and told
a story. Apparently many hundreds of years ago a fellow made a flying
device (similar to Icarus) and jumped off a building and flew down the
hill.

At the bottom, he was seen by a crowd of people who though he was a
flying devil and proceeded to quickly kill him.

Who were the idiots? the ones believing in flying-devils who wouldn't
hesitate to murder or the one working to find a better way of travel?

But its value comes from its being a standard.

Walking was once a standard before cars, trains and aeroplanes. Times
change Rick. Live and let live.

Regards

David

At 04:02 PM 2006-08-23 +1000, Rick Jelliffe wrote:
>Any idiot can make up a better markup language than XML, and many idiots
>in fact do so.
>
>
>Cheers
>Rick Jelliffe

Could you please show us your version of a better markup language than XML?
Would your version include GXTC?

Thanks.

cheers,
mc

David Lyon <david.lyon (AT) preisshare (DOT) netwrites:
Wed, 2006-08-23 at 16:02 +1000, Rick Jelliffe wrote:
>Any idiot can make up a better markup language than XML, and many idiots
>in fact do so.
>
I think this is a very condescending statement about the people like
David Megginson who put XML together. Saying that it only takes an idiot
to do better. You obviously have no understanding of the skills,
hardships, determination and sacrifices of any person who tries to
advance the common knowledge.

Don't worry, Rick was there too:

Regards,

Tony.

David Lyon <david.lyon (AT) preisshare (DOT) netwrites:
Wed, 2006-08-23 at 16:02 +1000, Rick Jelliffe wrote:
>Any idiot can make up a better markup language than XML, and many idiots
>in fact do so.
>
I think this is a very condescending statement about the people like
David Megginson who put XML together. Saying that it only takes an idiot
to do better. You obviously have no understanding of the skills,
hardships, determination and sacrifices of any person who tries to
advance the common knowledge.

Don't worry, Rick was there too:

Regards,

Tony.

Nice to see XML-DEV back after its outage. Perhaps a good time to pay
tribute to Henry Rzepa and colleagues at Imperial college who ran the
XML-DEV list in its first three years without a glitch. We had, I
think, 1 spam. Tempora mutantur

At 07:02 23/08/2006, Rick Jelliffe wrote:
>>
>I think Juan needs to look at goal # 10 for XML "Terseness is of
>minimal importance"
>and also the goal that there should be as few optional features as possible.

Many members of this list may not appreciate the enormous communal
effort made by the XML community in 1997 The 10 goals of XML were
critical and have inspired Henry and me in our development of CML -
we adopted those which were directly relevant and added a few more
concerned with chemistry. course we took XML as a given.


>Any idiot can make up a better markup language than XML, and many
>idiots in fact do so.
>But its value comes from its being a standard.

Exactly so. No one realised this better than Jon Bosak - father of
XML - who at an XML meeting (?XML1999?) said at a plenary something like:
" be very careful what you do as you are setting the standard for the
next 30 years." (If anyone has the exact quote and event I'd be
grateful). The XML family of languages shows the whole spectrum of
quality - I won't comment individually but we are "stuck with" XSLT,
XSL-F, XSD, RELAX, SAX, Namespaces, MathML, SVG Some I love and
some I learn to live with, without complaint.

If you are going to innovate, build on top of this family. We've done
this for CML. We were very conscious of Jon's dictum when we built
the language. Some of the early constructs were built in the time of
DTDs - before dataTypes in XSD - and are ugly. Luckily we can
"deprecate" them without too much trouble. But whenever I get a CML
WIBNI I tell the requester that if we put it in and get it wrong it
can never be removed. I also tell them that it has to be implemented
and either they have to write the code or they have to persuade me to
lose even more sleep. It's very easy to come up with WIBNIs. People
have to fight very hard for new features.

It is very hard to develop successful scalable distributable systems.
XML was originally "SGML on the web". It was not promoted by the W3C.
Most people expected it to wither and die stillborn. The key to
success was the united enthusiasm and directed energy of about 100
active developers. Tim Bray (?at Granada) said that he has lived XML
for ?2 years. The success arose out of the cohesiveness of the SGML
community, the fresh blood injected by the Web, and the discipline. I
think I saw that XML was described as the "revenge of the over
40's". Among the many contributions of this list (which I'd
recommend new members to browse through) was the adoption of an
IETFlike insistence that any spec had to be shown to be
implementable. Norbert Mikola, James Clark, Tim Bray (and others
including even me) wrote parsers that tested whether XML was
sufficiently carefully designed and documented to be workable.

Remember also that XML was a direct descendant of SGML. SGML was
typical first version system - over-ambitious and (I believe) never
fully implemented in a single piece of software. Henry and I
developed CML as an SGML DTD. Without namespace it was hideous to try
to integrate HTML and CML, for example. XML was an enormous relief
when the only working free software for SGML was nsgmls.

"XML is the digital dial tone of the Web" - again I think that's Jon
Bosak. I assume that there are now (or soon will be) chips that are
XML-aware. I love it.

P.

Peter Murray-Rust
Unilever Centre for Molecular Sciences Informatics
University of Cambridge,
Lensfield Road, Cambridge CB2 1EW, UK
+44-1223-763069

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></tagvs. </tag>
- Multiple sintaxes for authoring
- DTD entities vs, PI entities, vs. Schema entities vs
- XSL-F vs CSS.
- HTML link vs. Xlinx vs. Hlink
- Etc.

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. 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.

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 CANNICAL |SCIENCE)

my 5c

</is a syntax element and as long as something else understands the
semantics - it will do fine

however

</tagis semantic which means the parser/processor does not need
external information to make a descision about the correctness and
completeness of the information.

For those who remember the programming language discussions of 20+ years
ago (and today?) this issue must have a strong feeling of deja vu.

eg

function X {} /* end of X */

;)

rick

juanrgonzaleza (AT) canonicalscience (DOT) com wrote:

>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></tagvs. </tag>
>
>- Multiple sintaxes for authoring
>
>- DTD entities vs, PI entities, vs. Schema entities vs
>
>- XSL-F vs CSS.
>
>- HTML link vs. Xlinx vs. Hlink
>
>- Etc.
>
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. 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.
>
>>
>>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 CANNICAL |SCIENCE)
>
>
>
>!DSPAM:44ed5e1a294179734571689!
>

Rick Marshall said:
my 5c

</is a syntax element and as long as something else understands the
semantics - it will do fine

however

</tagis semantic which means the parser/processor does not need
external information to make a descision about the correctness and
completeness of the information.

<tag1>content1<tag2>content2</tag2></tag1>

parsed <tag1and <tag2the parser finds the "</" and *wait* a
"tag2" because consistency of the XML. The same when finds the </tag1>.

<tag1>content1<tag2>content2</></>

parsed <tag1and <tag2the parser finds the "</" and knows/assumes
is closing the open tag2 because consistency of XML. The same when finds
the last </>.

No external information is needed. Differences:
- With </tag-namethe closing is pre-defined in the doc. With </it is
*not* predefined, in the sense that the tag always closes the latter empty
tag.
- Therefore, we return to begin of this thread. In certain dinamical docs
the value of the end tag cannot be known _a priori_ and </tag-nameis of
no utility here. Therefore the need for the option </>.
- Sometimes the end tag of XML can be of help when parsing erroneous docs.

Therefore sometimes </end-tagcan be better than </>; sometimes </can
be better than </end-tag>.

For those who remember the programming language discussions of 20+ years
ago (and today?) this issue must have a strong feeling of deja vu.

eg

function X {} /* end of X */

Today also! In fact there is still debate specially between people
developing new PLs on what is better option LISP/C syntaxes or Pascal
like.

The inmmense popularity of C syntax

function X {}

or LISP one

(function X )

over Pascal like blocks

begin function X end function

offers an idea on why </is being promoted for PL applications.

Your explicit quoting of comments at end of function is very interesting
because it is the common reply to the human readability of XML end tags
becoming from LISP/Scheme community. I also agree that something like

[::section
"300 pages of code here"
#end section of line 24]

is more readable than

<section>
"300 pages of code here"
</section>

About verbosity, this

<temperature>300</>

is less verbose than

<temperature>300</temperature>

in a large factor. Imagine a large sample from laboratory

;)

rick

P.S. CSS does not use end tags H2 {}

Juan R.

Center for CANNICAL |SCIENCE)

juanrgonzaleza (AT) canonicalscience (DOT) com wrote:

>Rick Marshall said:

>
>>my 5c
>>
>></is a syntax element and as long as something else understands the
>>semantics - it will do fine
>>
>>however
>>
>></tagis semantic which means the parser/processor does not need
>>external information to make a descision about the correctness and
>>completeness of the information.
>
>>
>
><tag1>content1<tag2>content2</tag2></tag1>
>
parsed <tag1and <tag2the parser finds the "</" and *wait* a
>"tag2" because consistency of the XML. The same when finds the </tag1>.
>
><tag1>content1<tag2>content2</></>
>
parsed <tag1and <tag2the parser finds the "</" and knows/assumes
>is closing the open tag2 because consistency of XML. The same when finds
>the last </>.

assuming is not the same as knowing.

i mean lets have some real fun - like in html and allow </to close off
all unclosed tags. saves a few more keystrokes.

<tag1><tag2></>

now that's even more compact and it's sort of what html does - but we
all know how often it gets it wrong.

you see the problem is that when the parser comes across </it has to
ASSUME that it is closing the last declared tag. however if you
accidentally left out a close tag then it's wrong and it will take
counting opening and closing tags right to the end of the document to
know that the document is valid.

bye bye sax

rick

>No external information is needed. Differences:
>
>- With </tag-namethe closing is pre-defined in the doc. With </it is
>*not* predefined, in the sense that the tag always closes the latter empty
>tag.
>
>- Therefore, we return to begin of this thread. In certain dinamical docs
>the value of the end tag cannot be known _a priori_ and </tag-nameis of
>no utility here. Therefore the need for the option </>.
>
>- Sometimes the end tag of XML can be of help when parsing erroneous docs.
>
>Therefore sometimes </end-tagcan be better than </>; sometimes </can
>be better than </end-tag>.
>

>
>>For those who remember the programming language discussions of 20+ years
>ago (and today?) this issue must have a strong feeling of deja vu.
>>
>>eg
>>
>>function X {} /* end of X */
>
>>
>
>Today also! In fact there is still debate specially between people
>developing new PLs on what is better option LISP/C syntaxes or Pascal
>like.
>
>The inmmense popularity of C syntax
>
>function X {}
>
>or LISP one
>
>(function X )
>
>over Pascal like blocks
>
>begin function X end function
>
>offers an idea on why </is being promoted for PL applications.
>
>Your explicit quoting of comments at end of function is very interesting
>because it is the common reply to the human readability of XML end tags
>becoming from LISP/Scheme community. I also agree that something like
>
>[::section
>"300 pages of code here"
>#end section of line 24]
>
>is more readable than
>
><section>
>"300 pages of code here"
></section>
>
>About verbosity, this
>
><temperature>300</>
>
>is less verbose than
>
><temperature>300</temperature>
>
>in a large factor. Imagine a large sample from laboratory
>

>
>>;)
>>
>>rick
>>
>
>>
>
>P.S. CSS does not use end tags H2 {}
>
>
>Juan R.
>
>Center for CANNICAL |SCIENCE)
>
>
>
>
>!DSPAM:44eed359206911016417754!
>

Michael Kay said:
Juan Gonzalez wrote:
>
>The inmmense popularity of C syntax
>>
>function X {}
>>
>or LISP one
>>
>(function X )
>>
>over Pascal like blocks
>>
>begin function X end function
>
I think the Pascal syntax is actually:

FUNCTIN convert( degC: real ): real
BEGIN
convert := degC + 273.15;
END;

Yeah, this is a verbose version of curly braces or parentheses.

Structures of type

begin J

end J

or

\begin{J}

\end{J}

or

J

endJ

and variants are I mean by (Pascal like blocks) != (Pascal syntax)

If you're seriously arguing that C has been more successful than Pascal
*because* it used curly braces rather than BEGIN/END keywords then I
think you need a course in logic.

I said "the inmmense popularity of C syntax". I was talking of C like
syntax alone NT you are saying.

Pascal was designed so it could be
typed on European keyboards that didn't have curly braces; C used curly
braces because Americans didn't give a toss about that problem, or
didn't even know it existed.

Michael Kay
http://www.saxonica.com/

Juan R.

Center for CANNICAL |SCIENCE)

Rick Marshall said:

juanrgonzaleza (AT) canonicalscience (DOT) com wrote:
>
>>Rick Marshall said:
>>
>>
my 5c

</is a syntax element and as long as something else understands the
semantics - it will do fine

however

</tagis semantic which means the parser/processor does not need
external information to make a descision about the correctness and
completeness of the information.


>>
>><tag1>content1<tag2>content2</tag2></tag1>
>>
>parsed <tag1and <tag2the parser finds the "</" and *wait* a
>"tag2" because consistency of the XML. The same when finds the </tag1>.
>>
>><tag1>content1<tag2>content2</></>
>>
>parsed <tag1and <tag2the parser finds the "</" and
>knows/assumes is closing the open tag2 because consistency of XML. The
>same when finds the last </>.
>>
>>
assuming is not the same as knowing.

Sure, see below.

i mean lets have some real fun - like in html and allow </to close off
all unclosed tags. saves a few more keystrokes.

<tag1><tag2></>

now that's even more compact and it's sort of what html does - but we
all know how often it gets it wrong.

you see the problem is that when the parser comes across </it has to
ASSUME that it is closing the last declared tag. however if you
accidentally left out a close tag then it's wrong and it will take
counting opening and closing tags right to the end of the document to
know that the document is valid.

bye bye sax

rick

Right! Parser assume that end empty tag is closing last open tag. If the
doc is sintatically correct (i.e. tags, parenteses, curly braces
matching) then the parser knows what tag is closing each one. If some
start or end tag is missing, then you obtain error. Is that an advantage
of full empty tags over short forms as </>? Again no.

I repeat again that i discussed a bit this in

[]

The doc is a bit outdated by recent improvements but there I review Paul
Prescod arguments in pro of full end tags and that part is still valid. He
compared XML syntax and S-expressions, but the same apply to the special
XML syntax discussed here because </plays the role of the ")" of LISP.

Well he omitted a </footnoteand proved that XML parser does not need
parse the entire doc. Three comments:
- He used an XML oriented example. If missing the </paraafter the
</footnoteinstead then the XML parser needs to parse the entire doc
(except the root) before finding the error. Therefore the advantage of the
full end tag is lost.
- Contrary to XML, it is trivial to run a pre-parsing step where verified
syntaxis correctness, simply counting number of "{" and "}" (TeX, C) or
number of "(" and ")" (LISP, Scheme) or "[" and "]" (CanonML) in the
full doc.
- It is also simpler typping [] and next type the content inside than
<my-tag></my-tag>. By my own experience the number of errors typping XML
is more than double. This can be illustrated as,

Case "[]": Error posible? omision of some tag.

Case <tag></tag>: Errors possible? i) omision of some tag ii) incorrect
writting of tag, e.g. <tag><tag, <tag></tah>, <tag><7tag>

This is also noted in

[]

<blockquote>
The extra typing required to open and close tags and escape special
characters not only wastes time, but introduces more possibility for
error.
</blockquote>

I would also remark that there are ways to improve readability of () {} []
cases over the XML syntax and this also applies to the <tag></case.

Therefore i summarize.

Advantages of XML standard syntax:

1) Better readability in some special cases

2) In some special cases, the parser can find errors without parsing the
full document. This is real advantage only for large documents iff the
error is at the very beggining. can assume 1/4 errors in 4th (last)
part of docs and 1/4 in 1st part. Therefore, for each case of XML is real
advantage, you could find case where is not.

Disadvantages of XML standard syntax:

1) It is easy to generate more errors.

2) For avoiding above point you need special editor.

3) It is more verbose and less efficient for parsing.

4) Cannot deal with all cases, as those addressed by ConciseXML (and others).

5) The (small) advantage of full end tags is lost when generalizing the
system to non-hierarchies, one of non-soved problems in XML. For instance
GDDAG approach

<a/ <b/ /a/b>

Advantages of special syntaxes:

I mean, SXML (), CanonML [], ConciseXML <tag></>, , XUL-C

1) Very good readability, specially with large naming tags and or
namespaces or when markup length is several order of magnitude that of
content.

In my experience, XSLT become more readable when omiting full end tags and
code is indented as shown here. thing the same:

<blockquote>
XSLT is often considered to be too verbose. As stylesheet code grows, it
tends to be unreadable.
</blockquote>

[http://www.xml.com/lpt/a/1226]

2) Lightweight parsers, specially with SXML and CanonML.

3) Less verbosity. And this _is_ a point with very large datuments,
therein some guides in the famous element vs. attribute dilema recommend
usage of attributes when size is an issue.

4) Do not need for special options as <tag></tagvs. <tag/>. Therefore
the small advantage of simple XML approaches is lost with special
syntaxes.

Disadvantages of special syntaxes:

1) In some cases it is more difficult to find sintax errors.

2) In some cases and for some pople the XML end tags increases readability.

3) If end tags are left as option, then parsers become more complex than
when parsing only XML.

5) Cannot deal with non-hierarchies in a direct way.

Each one can take a decision by her/himself. In some cases XML is good in
others you need alternative sintaxes or the </option There is not
absolute answer even if some XML folks desire one.

Juan R.

Center for CANNICAL |SCIENCE)

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.

</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.

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

juanrgonzaleza (AT) canonicalscience (DOT) com wrote:
Rick Marshall said:

>juanrgonzaleza (AT) canonicalscience (DOT) com wrote:
>>
>
Rick Marshall said:

my 5c

</is a syntax element and as long as something else understands the
semantics - it will do fine

however

</tagis semantic which means the parser/processor does not need
external information to make a descision about the correctness and
completeness of the information.

<tag1>content1<tag2>content2</tag2></tag1>

parsed <tag1and <tag2the parser finds the "</" and *wait* a
"tag2" because consistency of the XML. The same when finds the </tag1>.

<tag1>content1<tag2>content2</></>

parsed <tag1and <tag2the parser finds the "</" and
knows/assumes is closing the open tag2 because consistency of XML. The
same when finds the last </>.


>assuming is not the same as knowing.
>
>
Sure, see below.


>i mean lets have some real fun - like in html and allow </to close off
>all unclosed tags. saves a few more keystrokes.
>>
><tag1><tag2></>
>>
>now that's even more compact and it's sort of what html does - but we
>all know how often it gets it wrong.
>>
>you see the problem is that when the parser comes across </it has to
>ASSUME that it is closing the last declared tag. however if you
>accidentally left out a close tag then it's wrong and it will take
>counting opening and closing tags right to the end of the document to
>know that the document is valid.
>>
>bye bye sax
>>
>rick
>
>
Right! Parser assume that end empty tag is closing last open tag. If the
doc is sintatically correct (i.e. tags, parenteses, curly braces
matching) then the parser knows what tag is closing each one. If some
start or end tag is missing, then you obtain error. Is that an advantage
of full empty tags over short forms as </>? Again no.

I repeat again that i discussed a bit this in

[]

The doc is a bit outdated by recent improvements but there I review Paul
Prescod arguments in pro of full end tags and that part is still valid. He
compared XML syntax and S-expressions, but the same apply to the special
XML syntax discussed here because </plays the role of the ")" of LISP.

Well he omitted a </footnoteand proved that XML parser does not need
parse the entire doc. Three comments:

- He used an XML oriented example. If missing the </paraafter the
</footnoteinstead then the XML parser needs to parse the entire doc
(except the root) before finding the error. Therefore the advantage of the
full end tag is lost.

- Contrary to XML, it is trivial to run a pre-parsing step where verified
syntaxis correctness, simply counting number of "{" and "}" (TeX, C) or
number of "(" and ")" (LISP, Scheme) or "[" and "]" (CanonML) in the
full doc.

- It is also simpler typping [] and next type the content inside than
<my-tag></my-tag>. By my own experience the number of errors typping XML
is more than double. This can be illustrated as,

Case "[]": Error posible? omision of some tag.

Case <tag></tag>: Errors possible? i) omision of some tag ii) incorrect
writting of tag, e.g. <tag><tag, <tag></tah>, <tag><7tag>

This is also noted in

[]

<blockquote>
The extra typing required to open and close tags and escape special
characters not only wastes time, but introduces more possibility for
error.
</blockquote>

I would also remark that there are ways to improve readability of () {} []
cases over the XML syntax and this also applies to the <tag></case.

Therefore i summarize.

Advantages of XML standard syntax:

1) Better readability in some special cases

2) In some special cases, the parser can find errors without parsing the
full document. This is real advantage only for large documents iff the
error is at the very beggining. can assume 1/4 errors in 4th (last)
part of docs and 1/4 in 1st part. Therefore, for each case of XML is real
advantage, you could find case where is not.

Disadvantages of XML standard syntax:

1) It is easy to generate more errors.

2) For avoiding above point you need special editor.

3) It is more verbose and less efficient for parsing.

4) Cannot deal with all cases, as those addressed by ConciseXML (and others).

5) The (small) advantage of full end tags is lost when generalizing the
system to non-hierarchies, one of non-soved problems in XML. For instance
GDDAG approach

<a/ <b/ /a/b>
--
Advantages of special syntaxes:

I mean, SXML (), CanonML [], ConciseXML <tag></>, , XUL-C

1) Very good readability, specially with large naming tags and or
namespaces or when markup length is several order of magnitude that of
content.

In my experience, XSLT become more readable when omiting full end tags and
code is indented as shown here. thing the same:

<blockquote>
XSLT is often considered to be too verbose. As stylesheet code grows, it
tends to be unreadable.
</blockquote>

[http://www.xml.com/lpt/a/1226]

2) Lightweight parsers, specially with SXML and CanonML.

3) Less verbosity. And this _is_ a point with very large datuments,
therein some guides in the famous element vs. attribute dilema recommend
usage of attributes when size is an issue.

4) Do not need for special options as <tag></tagvs. <tag/>. Therefore
the small advantage of simple XML approaches is lost with special
syntaxes.

Disadvantages of special syntaxes:

1) In some cases it is more difficult to find sintax errors.

2) In some cases and for some pople the XML end tags increases readability.

3) If end tags are left as option, then parsers become more complex than
when parsing only XML.

5) Cannot deal with non-hierarchies in a direct way.
--
Each one can take a decision by her/himself. In some cases XML is good in
others you need alternative sintaxes or the </option There is not
absolute answer even if some XML folks desire one.
--
Juan R.

Center for CANNICAL |SCIENCE)
>
>
>
>
!DSPAM:44f03f82119817354971447!
--

<juanrgonzaleza (AT) canonicalscience (DOT) comwrites:

3) Less verbosity. And this _is_ a point with very large datuments,
therein some guides in the famous element vs. attribute dilema recommend
usage of attributes when size is an issue.

I'm not familiar with the word "datument". FWIW, nor is Google since
it asks "Did you mean: document".

Are you using it in the sense used by Peter Murry-Rust and Henry
S. Rzepa[1]:

A datument is a hyperdocument for transmitting "complete"
information including content and behaviour.

or in some other sense?

Regards,

Tony.

[1] #4

Tony Graham said:
<juanrgonzaleza (AT) canonicalscience (DOT) comwrites:

>3) Less verbosity. And this _is_ a point with very large datuments,
>therein some guides in the famous element vs. attribute dilema
>recommend usage of attributes when size is an issue.
>
I'm not familiar with the word "datument". FWIW, nor is Google since it
asks "Did you mean: document".

Are you using it in the sense used by Peter Murry-Rust and Henry
S. Rzepa[1]:

A datument is a hyperdocument for transmitting "complete"
information including content and behaviour.

or in some other sense?

Regards,
--
Tony.

[1] #4

Yes Tony, i mean very close to Murray-Rust word.

Look the glosary in the bottom part of the ref you cited

[]

Datument: a combination of data and document created using formal markup
to allow the processing of individual data components

Today scientific research is usually presented in a document form (PDF or
paper formats in usual journals). Most of scientific data generated in
research is lost in the end and often you even cannot check methodology,
statistical procedures

Peter Murray-Rust is one of folks who want to see a new way of scientific
communication where document ('worked data') are combined with raw data.

Some people would claim that documents are data, but i prefer
differentiation between both, somewhat as often we differentiate mixed
markup (usually documents) from non-mixed (usually data).

Juan R.

Center for CANNICAL |SCIENCE)