|
| | | Altova Mailing List Archives>Archive Index >xml-dev Archive Home >Recent entries >Thread Prev - Generic XML Tag Closer (GXTC) [Thread Next] Re: [xml-dev] Generic XML Tag Closer (GXTC)To: juanrgonzaleza@----------------.--- Date: 8/20/2006 1:42:00 AM juanrgonzaleza@c... 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
>
> [http://www.amazon.com/gp/product/1861005946/102-1558124-8994523?n=283155]).
>
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><BODY 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 <DIV> or <SPAN> was 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. Other, 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 </section> end tags at least
tells me that it isn't the number of <section> end 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="http://www.w3.org/1998/Math/MathML">
> <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="http://www.w3.org/1998/Math/MathML"
> [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. One 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="http://www.w3.org/1998/Math/MathML"
> [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.
>
> One 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
> [http://canonicalscience.blogspot.com/2006/04/canonml-markup-language-beyond-tex-xml.html]
>
> I wrote some basic arguments against claims by Paul Prescod that XML
> syntax is more robust in the face of errors. See also
>
> [http://www-128.ibm.com/developerworks/xml/library/x-syntax.html?loc=x]
>
>
No doubt an interesting article and conversation. I'll go look.
Regards
- Mitch
> Juan R.
>
> Center for CANONICAL |SCIENCE)
>
>
>
> | |
| | ||||||||
| Company | Legal | Press | Partners | Careers | Sitemap | Contact Us | Altova Blog | Mobile | Full Site | |||
|
