Re: XML naming conventions and good practice

T

Tom Anderson

[crossposted to alt.usage.english!]

Probably slightly off topic, but hopefully someone can give me some
insight to best practice.
My problem is I've got an element that's name is an irregular noun,
in this case "series"
So all the "series" elements need to be put inside another element,
currently I'm using "seriesList" because the plural of series is
series:

<seriesList>
<series>...</series>
<series>...</series>
<series>...</series>
</seriesList>

A colleague told me that this may be considered bad practice in
naming XML elements.
Can someone with more experience with XML let me know if my solution
is alright?

I can't claim a lot of experience with XML, but seriesList does look a bit
clunky. I am tempted to suggest serieses as the name of the outer element!

Can you call series something else? There are other words that mean much
the same thing - list, sequence, succession, chain, run - all of which
have normal plurals. Or is series a word from your domain vocabulary that
can't be changed?

tom
 
P

Peter Duncanson (BrE)

[crossposted to alt.usage.english!]

Probably slightly off topic, but hopefully someone can give me some
insight to best practice.
My problem is I've got an element that's name is an irregular noun,
in this case "series"
So all the "series" elements need to be put inside another element,
currently I'm using "seriesList" because the plural of series is
series:

<seriesList>
<series>...</series>
<series>...</series>
<series>...</series>
</seriesList>

A colleague told me that this may be considered bad practice in
naming XML elements.
Can someone with more experience with XML let me know if my solution
is alright?

I can't claim a lot of experience with XML, but seriesList does look a bit
clunky. I am tempted to suggest serieses as the name of the outer element!

Can you call series something else? There are other words that mean much
the same thing - list, sequence, succession, chain, run - all of which
have normal plurals. Or is series a word from your domain vocabulary that
can't be changed?
I've never created XML stuff, but from work in other contexts I'd
suggest <series_set> or <series_group>.
 
J

James Hogg

[crossposted to alt.usage.english!]

Probably slightly off topic, but hopefully someone can give me some
insight to best practice.
My problem is I've got an element that's name is an irregular noun,
in this case "series"
So all the "series" elements need to be put inside another element,
currently I'm using "seriesList" because the plural of series is
series:

<seriesList>
<series>...</series>
<series>...</series>
<series>...</series>
</seriesList>

A colleague told me that this may be considered bad practice in
naming XML elements.
Can someone with more experience with XML let me know if my solution
is alright?

I can't claim a lot of experience with XML, but seriesList does look a bit
clunky. I am tempted to suggest serieses as the name of the outer element!

Can you call series something else? There are other words that mean much
the same thing - list, sequence, succession, chain, run - all of which
have normal plurals. Or is series a word from your domain vocabulary that
can't be changed?
I've never created XML stuff, but from work in other contexts I'd
suggest <series_set> or <series_group>.

The OED has these quotations:

"1765 W. WARD Grammar IV. iv. 167 Several participles cannot
conveniently be used so as to affect every part of long serieses
of words immediately."

"1797 Encycl. Brit. (ed. 3) XVIII. 514/1 Two serieses are
completed in the exact time of a lunation."

Apparently the plural could be spelt (that's not Triticum spelta)
"serieses" or "series's" in the 17th and 18th centuries.

Not that I'm recommending it for use today. Your solution looks
good.
 
P

Peter Duncanson (BrE)

[crossposted to alt.usage.english!]

Probably slightly off topic, but hopefully someone can give me some
insight to best practice.
My problem is I've got an element that's name is an irregular noun,
in this case "series"
So all the "series" elements need to be put inside another element,
currently I'm using "seriesList" because the plural of series is
series:

<seriesList>
<series>...</series>
<series>...</series>
<series>...</series>
</seriesList>

A colleague told me that this may be considered bad practice in
naming XML elements.

Is there a convention that lower-case letters should normally be used
and that words should be separated with an underscore?

That would mean <seriesList> would be more conventionally written as
 
J

Joe Kesselman

Is there a convention that lower-case letters should normally be used
and that words should be separated with an underscore?

Not a generally-agreed-upon convention, no. As with other programming
conventions, the important thing is more that you are consistent within
your own domain than that you do things exactly the same way as other
projects do.
That would mean <seriesList> would be more conventionally written as
<series_list>.

Both are equally acceptable as far as XML conventions are concerned.
Your company's conventions may be a different matter.
 
P

Prai Jei

James Hogg set the following eddies spiralling through the space-time
continuum:
The OED has these quotations:

"1765 W. WARD Grammar IV. iv. 167 Several participles cannot
conveniently be used so as to affect every part of long serieses
of words immediately."

"1797 Encycl. Brit. (ed. 3) XVIII. 514/1 Two serieses are
completed in the exact time of a lunation."

Apparently the plural could be spelt (that's not Triticum spelta)
"serieses" or "series's" in the 17th and 18th centuries.

Not that I'm recommending it for use today. Your solution looks
good.

Isn't series already a plural? (F only knows what the singular might have
been though.) No probs with spelt by the way, I'm a native BrE speaker.

I've had some dabblings in XML, and just recently we had somebody in charge
of the system we're trying to link to, saying that our test XML output was
OK, so next day our engineer travelled 50 miles to the customer's site to
install our system, and in the middle of that an email arrived back at our
office, pointing out a fault that needed a little tweak. (One tag appeared
twice without its antitag.) AAAAARGH!! Why couldn't you have told us this
yesterday? Thank f for websites like YouSendIt.

My main gripe against XML is that it's so verbose. In this particular
application, tags and antitags take up more than ten times as much space as
the actual data being sent. CSV was *so* much more compact.
 
J

Joe Kesselman

My main gripe against XML is that it's so verbose. In this particular
application, tags and antitags take up more than ten times as much space as
the actual data being sent. CSV was *so* much more compact.

XML's verbosity is part of what's made it rapidly accepted -- it's easy
to debug.

On the other hand, XML has never claimed to be the right answer for all
tasks. If CSV is right for your needs, by all means use CSV. Or use
whatever representation you like internally, with an export/import tool
that converts between your representation an XML for interchange with
others.

On the other other hand, XML typically compresses magnificently, and a
compressed XML file may take no more space than the compressed CSV file
would have.
 
J

JimboCat

XML's verbosity is part of what's made it rapidly accepted -- it's easy
to debug.

On the other hand, XML has never claimed to be the right answer for all
tasks.

Microsoft, on the other hand, has effectively claimed so. Well, maybe
not *all* tasks. But my new computer at work has Office 2007. Not only
do I hate the new user-interfaces, but it turns out the new file
format is . . .

wait for it . . .

a zip file full of XML docs.

Features were lost in the transformation. At least I think so: with
the new user-interface I can't find half the features I used to use
daily.

Jim Deutch (JimboCat)
 
J

Joe Kesselman

Features were lost in the transformation. At least I think so: with
the new user-interface I can't find half the features I used to use
daily.

That's certainly not XML's fault. Someone else can defend Microsoft, if
so inclined.

(For what it's worth, I'm told everything is still there, it's just that
it's all somewhere else. The hot-keys still work, but the menus which
reminded you what the hot keys were have evaporated. It's a lot more
biased toward mouse than it used to be. Personally, I never used Word so
I have absolutely no opinion, but I do have one friend who thinks it's a
net improvement.)
 
M

musika

In
JimboCat said:
Microsoft, on the other hand, has effectively claimed so. Well, maybe
not *all* tasks. But my new computer at work has Office 2007. Not only
do I hate the new user-interfaces, but it turns out the new file
format is . . .

wait for it . . .

a zip file full of XML docs.

Features were lost in the transformation. At least I think so: with
the new user-interface I can't find half the features I used to use
daily.

Others feel the same. If you are that bothered, you may be interested in:
http://www.addintools.com/english/menuword/
 
P

Peter Flynn

Prai said:
My main gripe against XML is that it's so verbose. In this particular
application, tags and antitags take up more than ten times as much space as
the actual data being sent. CSV was *so* much more compact.

CSV is for rectangular data one level deep. If that is the extent of
your data, then possibly CSV is a better way to represent it.

Try representing the following in CSV. It might be possible, but I
submit that XML was the correct choice in this instance.

<div0 type="law tract">
<div1 type="primary text">
<p><lb n="4"><term id="g1">Is mesiuch cach fear fine cunai a
fintiud</term> <term id="g2">naide rean</term> <term id="g3">naide
<lb n="5">sannu</term> <term id="g4">naide fotlean</term> <term
id="g5">naide fuich cintuib</term> <term id="g6">na coruib is mesi
imusfuich</term> <term id="g7">curu a fine</term> <lb n="6"><term
id="g8"> imfuich cach curud a comfocuis</term> <term id="g9">mad e
araneastur a <lb n="7">cintu &ampersir;</term> <term id="g10">a
rathu</term> <term id="g11">&ampersir; a curu</term> <term
id="g12">&ampersir a chiniuda</term> <term id="g13">&ampersir; a
gnimu orba</term> <term id="g14">cu niarduige <lb n="8">gaire
adruidleacht finntiu</term></p></div1> <div1 type="glossatorial
text"> <p><gloss target="g1">.i. <lb n="9">is cuimgeach cach fear
coimed a feruinn cin a rec fri indetbirius ar .s.uibh</gloss> <lb
n="10">urchruide <gloss target="g2">.i. im ni de</gloss> <gloss
target="g3">.i. uime uile, &lstrok; fo taob mic foesaim d'ainfine
<lb n="11">.i. na sgailend</gloss> <gloss target="g4">.i. fo taeb
mic faesuim, ima rec a nindetbirus</gloss> <gloss
target="g5">.i. <lb n="12">indetbiri ele</gloss> <gloss
target="g6">.i. indetbiri .i. celsine indligthech</gloss><gloss
target="g7">.i. is cuimgiuch &eacute; <lb n="13">eim-fuaitriudh na
cor doniat in finechaire</gloss> <gloss target="g8">is eim fuaitrius
cac curu inti <lb n="14">is comfochus don finechaire o bias
amluidh-sin</gloss> <gloss target="g9">.i. ma &eacute; urfethius a
cinta <lb n="15">coisi &ampersir; laime</gloss> <gloss
target="g10">.i. a cinta rathachuis .i. fri hannsguiche .i. a gnim
raithe &ampersir; <lb n="16">etire</gloss> <gloss
target="g11">.i. fri sguiche .i. fuaitriud cor etar dis</gloss>
<gloss target="g12">.i. altrum a clainne</gloss> <gloss
target="g13"><lb n="17">.i. d'fuba &ampersir; do ruba</gloss> <gloss
target="g14">.i. nach gnim dlegar den orbar, &ampersir gaire na <lb
n="18">seanfine biti cin clainn, rodligustur finntiu de-sium sin
.i. cusin iarum-dighe <lb n="19">is adha do dlechtuin don fir fine,
gaire int senorach coitcind. i. do neoch <lb n="20">dligus a gaire a
finntiud</gloss></p>
</div1>
</div0>

///Peter
 
P

Peter Flynn

JimboCat said:
Microsoft, on the other hand, has effectively claimed so. Well, maybe
not *all* tasks. But my new computer at work has Office 2007. Not only
do I hate the new user-interfaces, but it turns out the new file
format is . . .

wait for it . . .

a zip file full of XML docs.

Features were lost in the transformation. At least I think so: with
the new user-interface I can't find half the features I used to use
daily.

Office "productivity" packages are for writing business letters, doing
simple calculations, making presentation slides, or handling transient
or trivial information. They are inappropriate for large or persistent
documents, or for important or complex documents of any size, as they
lack the proper controls necessary to ensure the integrity of your
information. By default they only represent the visual appearance of
your work, not its internal structure or the reason why things are where
they are.

Individuals or businesses pinning their continued existence on the
reliability or reusability of information committed to these packages
must take extensive (and expensive) additional steps to safeguard that
information against misinterpretation, misrepresentation, and
deterioration. Such packages are attractive to users solely because of
their interface, and management which fails to realise this is failing
in its duty to the organisation, and demonstrating a lack of
understanding of the nature of business and professional information.

Fortunately, most business documents are relatively transient or
trivial, and not of any significace beyond the immediate ambit of the
decision they were written to inform, and can safely be discarded
afterwards; so the applications used, and the file formats created, are
not critical. Other, more important, documents can certainly be drafted
with such packages, but for persistence and usability beyond the
earliest stages they should be edited and stored using software and file
formats of proven reliability and accessibility.

///Peter
 
R

Robin Bignall

That's certainly not XML's fault. Someone else can defend Microsoft, if
so inclined.

(For what it's worth, I'm told everything is still there, it's just that
it's all somewhere else. The hot-keys still work, but the menus which
reminded you what the hot keys were have evaporated. It's a lot more
biased toward mouse than it used to be. Personally, I never used Word so
I have absolutely no opinion, but I do have one friend who thinks it's a
net improvement.)

That's exactly right, Joe. I find it more difficult to get to grips
with than Word 2002, from which I migrated.
(Nice to see you here in AUE: reminds me of the forums back in the
day...)
 
P

Prai Jei

Peter Flynn set the following eddies spiralling through the space-time
continuum:
Prai Jei wrote:
CSV is for rectangular data one level deep. If that is the extent of
your data, then possibly CSV is a better way to represent it.

Which it was - sales information from a till. (Item sold, quantity, price,
account number.) It was the target system that required it in XML.
Try representing the following in CSV. It might be possible, but I
submit that XML was the correct choice in this instance.

<div0 type="law tract">
<div1 type="primary text">
<p><lb n="4"><term id="g1">Is mesiuch cach fear fine cunai a
fintiud</term> <term id="g2">naide rean</term> <term id="g3">naide
[ & mucel mo vpon þis wyse ]

<confused>
 
P

Peter Flynn

Prai said:
Peter Flynn set the following eddies spiralling through the space-time
continuum:


Which it was - sales information from a till. (Item sold, quantity, price,
account number.) It was the target system that required it in XML.

Ah. One of those. Nothing so simple as

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

That would certainly be verbose, but It's worth bearing in mind design
goal #10 of XML, "Terseness in XML markup is of minimal importance."
Try representing the following in CSV. It might be possible, but I
submit that XML was the correct choice in this instance.

<div0 type="law tract">
<div1 type="primary text">
<p><lb n="4"><term id="g1">Is mesiuch cach fear fine cunai a
fintiud</term> <term id="g2">naide rean</term> <term id="g3">naide
[ & mucel mo vpon þis wyse ]

It's from a mediaeval legal document written in Old Irish, with glosses
on the meaning of almost every phrase. Not easy to represent in any
system, especially when it's important because some of the laws might
still be in force.

///Peter
 
W

William

Features were lost in the transformation. At least I think so: with
the new user-interface I can't find half the features I used to use
daily.

They're on the other ribbon / thingy.
 
P

Prai Jei

Peter Flynn set the following eddies spiralling through the space-time
continuum:
Ah. One of those. Nothing so simple as

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

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. 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.
<div0 type="law tract">
<div1 type="primary text">
<p><lb n="4"><term id="g1">Is mesiuch cach fear fine cunai a
fintiud</term> <term id="g2">naide rean</term> <term id="g3">naide
[ & mucel mo vpon þis wyse ]

It's from a mediaeval legal document written in Old Irish, with glosses
on the meaning of almost every phrase. Not easy to represent in any
system, especially when it's important because some of the laws might
still be in force.

I wondered what language it was, it certainly looked Gaelic but the absence
of accents (acute or grave) on any vowels made it impossible to be certain.
 
S

Stefan Ram

Peter Flynn said:
Ah. One of those. Nothing so simple as
<transaction id="abc123">
<item code="xyz789" quantity="3" price="29.99" account="1234567890"/>
</transaction>
That would certainly be verbose, but It's worth bearing in mind design
goal #10 of XML, "Terseness in XML markup is of minimal importance."

Is it so verbose?

The major redundancy I see is the end tag.

But that's about it.

On might say that a Java call

item("xyz789",3,29.99,1234567890)

is shorter to denotate the item, but this is only possible if
there are not many more possible attributes (which are omitted
above). Otherwise one needs a means to indicate which
attributes are given and which are omitted. But the XML call
with the attribute names is more readable.

When one tries to come up with something that is better than XML,
one sees that this is not that easy.
One might be able to do some fine tuning here and there.

Verbosity is not annoying as long as one gains something by it.
When one gains readability or robustness, it can be accepted.
 
S

Stefan Ram

Prai Jei 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

That sort of redundancy can easily and eficiently be
compressed using standard means. For example,
web browers can display pages compressed by gzip.
 
P

pdpi

Is it so verbose?

The major redundancy I see is the end tag.

But that's about it.

On might say that a Java call

item("xyz789",3,29.99,1234567890)

is shorter to denotate the item, but this is only possible if
there are not many more possible attributes (which are omitted
above). Otherwise one needs a means to indicate which
attributes are given and which are omitted. But the XML call
with the attribute names is more readable.

When one tries to come up with something that is better than XML,
one sees that this is not that easy.
One might be able to do some fine tuning here and there.

Verbosity is not annoying as long as one gains something by it.
When one gains readability or robustness, it can be accepted.

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.

On finding something better than XML... Well, depends entirely on what
you're trying to achieve. XML is a great way to deal with information
that can be effectively rendered as a decorated tree, but you'll often
see many other data types shoehorned into XML files. In particular,
text-encoded binary information embedded in XML files is the spawn of
a hundred devils.

(More on topic: "can hardly consider", or "can't hardly consider"? a
quick googling of "hardly" yields several cases of "can't hardly",
but, to me, that parses as an equivalent of "could care less".)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top