Newbie question on elements vs. attributes

[Pookee]

I am new to XML and having trouble deciding when data should be stored
as an attribute of an element or as an element of its own. In the
example:

<Books>
<Book pages="808">
<Title>C# Design Patters</Title>
<Author>Burton, Kevin</Author>
<Publisher>Sams</Publisher>
....

What are the rules for determining that the number of pages of the
book should be an attribute of the <Book> element while the other
information about the book such as title, author, and publisher are
stored as child elements?

Thanks in advance for any help,

Greg

 

[Stefan Ram]

<Books>
<Book pages="808">
<Title>C# Design Patters</Title>
<Author>Burton, Kevin</Author>
<Publisher>Sams</Publisher>
What are the rules for determining that the number of pages of the
book should be an attribute of the <Book> element while the other
information about the book such as title, author, and publisher are
stored as child elements?

The short answer is, that the criteria that makes sense can
not be used in XML, and so instead heuristics are used,
actually this situation is a mess.

A slightly longer answer:

An element is a description of an entity (this is its
semantics). (No, not an "entity" in the sense of the
XML-specification, but in the general sense of the
word as "something".)

A description is an assertion. An assertions might use unary
predicates or binary relations.

The structure of predicates and relations, thus, suggests that
a unary predicate is mapped to an element type (one value),
while a binary relation is mapped to a attribute (two values).

For example, say "x" is a rose and belongs to Jack. The
assertion is

rose(x) and owner(x,jack)

this maps to

<rose owner=jack />

in XML. So my answer would be: Use element types for unary
predicates and attributes for binary relations.

However, in XML, this is not always possible, because there
might be at most one element type and relation name per
element and relation values cannot be structured.

Therefore, people start to (ab)use element types as names of
binary relations, when their value is structured or multiple
values are needed, such as in:

<rose>
<owner>jack</owner>
<owner>jill</owner></rose>

So the restrictions of XML forbid to map the semantics
directly to syntax. (Without those restrictions there would be
less need for RDF, because the semantics of XML alone would be
nearly as expressive as RDF.)

Some people now suggest to always use sub-elements, because
one can never know, when a value of an attribute might need to
become structured. Or, recommend to use attributes only,
when one is confident that there will never be need for
a structured value or multiple values.

Others simply explain, that they use attributes as often as
possible, because they are easier to edit with their current
XML-editor.

Others make the choice based on how CSS might be used to
format their XML-documents.

(I am using my own XML-like notation, which allows for
structured and multiple values of attributes, and so I can
really map unary predicates to element types and binary
relations to attributes.)

 

[Stefan Ram]

<Books>
<Book pages="808">
<Title>C# Design Patters</Title>
<Author>Burton, Kevin</Author>
<Publisher>Sams</Publisher>
What are the rules for determining that the number of pages of the
book should be an attribute of the <Book> element while the other
information about the book such as title, author, and publisher are
stored as child elements?

The short answer is, that the criteria that makes sense can
not be used in XML, and so instead heuristics are used,
actually this situation is a mess.

A slightly longer answer:

An element is a description of an entity (this is its
semantics). (No, not an "entity" in the sense of the
XML-specification, but in the general sense of the
word as "something".)

A description is an assertion. An assertion might use unary
predicates or binary relations.

The structure of predicates and relations, thus, suggests that
a unary predicate is mapped to an element type (one value),
while a binary relation is mapped to an attribute (two values).

For example, say "x" is a rose and belongs to Jack. The
assertion is

rose(x) and owner(x,jack)

this maps to

<rose owner="jack" />

in XML. So my answer would be: Use element types for unary
predicates and attributes for binary relations.

However, in XML, this is not always possible, because there
might be at most one element type and relation name per
element and relation values cannot be structured.

Therefore, people start to (ab)use element types as names of
binary relations, when their value is structured or multiple
values are needed, such as in:

<rose>
<owner>jack</owner>
<owner>jill</owner></rose>

So the restrictions of XML forbid to map the semantics
directly to syntax. (Without those restrictions there would be
less need for RDF, because the semantics of XML alone would be
nearly as expressive as RDF.)

Some people now suggest to always use sub-elements, because
one can never know, when a value of an attribute might need to
become structured. Or, recommend to use attributes only,
when one is confident that there will never be need for
a structured value or multiple values.

Others simply explain, that they use attributes as often as
possible, because they are easier to edit with their current
XML-editor.

Others make the choice based on how CSS might be used to
format their XML-documents.

(I am using my own XML-like notation, which allows for
structured and multiple values of attributes, and so I can
really map unary predicates to element types and binary
relations to attributes.)

 

[Jukka K. Korpela]

I am new to XML and having trouble deciding when data should be stored
as an attribute of an element or as an element of its own.

This was asked rather recently. Did you miss to check the recent
discussions?

<Book pages="808">

Maybe a borderline case, since the number of pages might be regarded as a
genuine property of an element. But maybe not; it's not that different
from other bibliographic information.

But if you used some other data format instead of XML, like a simple
sequence of
name: value
pairs, you would probably not have even dreamt of making the number of
pages something special, and you wouldn't have felt a compelling need for
some "attributes" beyond the simple structure.

 

[Andy Dingley]

I am new to XML and having trouble deciding when data should be stored
as an attribute of an element or as an element of its own. In the
example:

<Books>
<Book pages="808">
<Title>C# Design Patters</Title>
<Author>Burton, Kevin</Author>
<Publisher>Sams</Publisher>

There aren't many reasons to make something an attribute.

There are a few reasons that strongly suggest making it an element.
One is any need for internal structure, such as child elements.
Another is that this entity might need to exist independently in its
own XML document.

Apart from this, you're pretty much on your own. If it mattered more,
it would be easier to choose and more obvious.

In some cases (such as XHTML) there may be an assumed behaviour in
readers such that attributes of unknown elements gets ignored, but
text content within an element gets shown. This can influence you too.

If you look at rules for writing a few well-known schemas in XML (RDF
and Dublin Core spring to mind) then there are deliberately two
descriptions of how to do this, one based on attributes and one based
on elements with text content.

What are the rules for determining that the number of pages of the
book should be an attribute of the <Book> element while the other
information about the book such as title, author, and publisher are
stored as child elements?

I don't know - is this an example you took from somewhere ? It's a
pretty poor example of real practice, although it's OK as a
rudimentary XML teaching example.

As a critique, it confuses "book" and "edition". Imagine there's a
hardback and paperback version. These have the same author and title,
but the ISBN and binding are different. If they're represented as
entirely separate "books", then you're forced to duplicate a lot of
information between them and there's still no way to see that they're
related.

There's also the question of nominal data.

<Publisher>Sams</Publisher>

is OK, but it's hard to work with if you need to recognise many books
from the same publisher. Is
<Publisher>Sams</Publisher>
the same as
<Publisher>Sams Publishing Corp.</Publisher>
or
<Publisher>Sams Scientific and Technical</Publisher>


Better practice is to introduce a controlled vocabulary, and to re-use
the references to the entries as much as possible.


<Publisher>http://example.org/vocabs/biblio/publishers/Sams/</Publisher>

or even
<Book
publisher="http://example.org/vocabs/biblio/publishers/Sams/"

 

[Peter Flynn]

I am new to XML and having trouble deciding when data should be stored
as an attribute of an element or as an element of its own.

This is a FAQ. See http://www.ucc.ie/xml#attriborelem

///Peter