Re: XML naming conventions and good practice

Stefan Ram · May 18, 2009

pdpi said:
Trying to come up with a way to nest tags without proper tag closing
is a nightmare, so I can hardly consider closing tags redundant.

I was refering to the repetition of the element type in the
closing tag.

Unotal, another language for annotated trees, would render

<transaction id="abc123">
<item code="xyz789" quantity="3" price="29.99" account="1234567890"/>
</transaction>

as

< &transaction id=abc123
< &item code=xyz789 quantity=3 price=29.99 account=1234567890 >>

It uses ">" instead of "</transaction>". So this is shorter, but it
might be more difficult to find errors in human-written code or to
be read by a human.

(Attribute values need only be quoted in Unotal if they contain
special characters the set of which does not include
characters matched by the regular expression [a-z0-9.] as used
in the attribute values above.)

http://www.purl.org/stefan_ram/pub/unotal_en

The Magpie · May 18, 2009

Stefan said:
Unotal, another language for annotated trees, would render

<transaction id="abc123">
<item code="xyz789" quantity="3" price="29.99" account="1234567890"/>
</transaction>

Stefan, this is a discussion that was beaten to death during the
development phase of XML. It was - pretty much universally - accepted
that your position had some supporters but was bad coding. Yes, XML is
a bit "wordier" but its a helluva lot simpler to track errors.

Stefan Ram · May 18, 2009

The Magpie said:
Stefan, this is a discussion that was beaten to death during the
development phase of XML. It was - pretty much universally - accepted
that your position had some supporters but was bad coding. Yes, XML is

Thanks for the report about the developement phase of XML.
I appreciate to learn that people actually care to consider
other possibilities. But SGML compatibility might also have
been important.

a bit "wordier" but its a helluva lot simpler to track errors.

Some of those errors can not be made in the first place, otherwise.

For example,

<alpha><beta></alpha></beta>

. The element types in the closing tags allows us to detect the
error of a wrong order. Without those names,

< &alpha < &beta >>

, it is not possible to make this error at all.

Another example,

<alpha><beta></alpha>

, allows us to infer the type of the missing end tag as »beta«.

Without the type,

< &alpha < &beta >

, we do /not/ know /which/ end tag is missing, just that one
end tag is missing, but without element types in end tags. we
also /do not need/ to know which end tag is missing.

And so on. (Lisp programmers are quite happy without named
end tags.)

Peter Flynn · May 18, 2009

pdpi said:
Trying to come up with a way to nest tags without proper tag closing
is a nightmare, so I can hardly consider closing tags redundant.

This was why SGML allowed you to declare them optional, where
syntactically possible. Here is an example HTML document:

<!doctype html system "html2.dtd" [
<!entity % html.recommended 'ignore'>
]>
<title>Demo</title>
<p>Hello, world!

This is completely valid, which you can test by normalizing it, eg:

$ sgmlnorm /usr/local/lib/sgml/sgmlhtml.dec demo.html
<HTML>
<HEAD>
<TITLE>Demo</TITLE>
</HEAD>
<BODY>
<P>Hello, world!</P>
</BODY>
</HTML>

All the markup that was implied by being declared omissible in the DTD
can correctly be inferred by a validating parser. There were other
options to make the markup even terser, to the point of human-unreadability.

Unsurprisingly, this was one of the first things to go in XML

///Peter

Peter Flynn · May 19, 2009

Prai said:
That sort of thing but there are a few more fields requested. The
verbosity of the output format is significant if the data has to be
transmitted across a s---l---o---w wide area network connection. Ties
up the till too long, customers leave the checkout queue and walk
out.

If it is a business requirement to transmit the data in real time to
somewhere else, then it is a business requirement to install a faster
connection...or...

We get round that by having the sales information written first to a
PC on the local network (fast) which then relays it to the target
system in its own time.

....use an alternative solution; this one sounds like a good idea.

The terseness aspect of XML was discussed at length during development.
The assumption was that network speeds would get faster in the future,
which they have, but not everywhere (I was staying last week in the UK,
in a location with only 48Kb/s dialup

, but as Stefan suggests, a
compression stream can help, as plaintext data like XML typically
compresses very well. Another possibility is use terser markup and
convert it the other end, eg

<t n="abc123"><i c="xyz789" q="3" p="29.99" a="1234567890"/></t>

or even just send CSV as you suggested, and convert to XML the other
end, but this may introduce its own redundancy if fields have to be
repeated in the normal form.

///Peter

XML DTD Validation, namespaces and best practices	1	Nov 2, 2005
xml and asp.net	4	Oct 20, 2006
comp.lang.c Answers to Frequently Asked Questions (FAQ List)	15	Apr 1, 2006
comp.lang.c Answers to Frequently Asked Questions (FAQ List)	1	Feb 1, 2004
comp.lang.c Answers (Abridged) to Frequently Asked Questions (FAQ)	0	Mar 1, 2008
comp.lang.c Answers (Abridged) to Frequently Asked Questions (FAQ)	0	Dec 15, 2007
comp.lang.c Answers (Abridged) to Frequently Asked Questions (FAQ)	0	Nov 1, 2007
comp.lang.c Answers (Abridged) to Frequently Asked Questions (FAQ)	0	Aug 1, 2007

Re: XML naming conventions and good practice

Stefan Ram

The Magpie

Stefan Ram

Peter Flynn

Peter Flynn

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads