about XML

[Tony Johansson]

Hello!

This question has nothing to do with the actual C# language but .NET is very
tight connected with XML so I assume
many of you are very used to XML therefore I ask this question.
I have two examples below and I just wonder which of these is the best. As
you can see the sex is used as an attribute in one of the example and as an
element in the other.

Can you give a comment which is best and why ?

<person sex="female">
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>

<person>
<sex>female</sex>
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>

//Tony

 

[sloan]

If you want to save a little space, then go @attribute based.

<person sex="female">

The only assumption is that you get one "sex". Which makes sense.
(<<Insert transvestite joke here I guess)

In the end, its your choice.

If you have sql server processing the xml, there is a bug with element based
shredding that got introduced with Sql Server 2005 SP2.
I have not tested the latest 2008 to see if its been fixed.
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=250407

 

[sloan]

If you want to save a little space, then go @attribute based.

<person sex="female">

The only assumption is that you get one "sex". Which makes sense.
(<<Insert transvestite joke here I guess)

In the end, its your choice.

If you have sql server processing the xml, there is a bug with element based
shredding that got introduced with Sql Server 2005 SP2.
I have not tested the latest 2008 to see if its been fixed.
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=250407

 

[Jesse Houwing]

Hello sloan,

If you want to save a little space, then go @attribute based.

<person sex="female">

The only assumption is that you get one "sex". Which makes sense.
(<<Insert transvestite joke here I guess)

If you ever work for healthcare you'd have seen the sex: MaleUsedToBeFemale
and vice versa...

And then you have hermafrodites and a number of other options.. You'd even
find a None option in there somewhere...

Ohh well...

Biology and Computer Science...

Jesse

 

[Jesse Houwing]

Hello sloan,

If you want to save a little space, then go @attribute based.

<person sex="female">

The only assumption is that you get one "sex". Which makes sense.
(<<Insert transvestite joke here I guess)

If you ever work for healthcare you'd have seen the sex: MaleUsedToBeFemale
and vice versa...

And then you have hermafrodites and a number of other options.. You'd even
find a None option in there somewhere...

Ohh well...

Biology and Computer Science...

Jesse

 

[Pavel Minaev]

This question has nothing to do with the actual C# language but .NET is very
tight connected with XML so I assume
many of you are very used to XML therefore I ask this question.
I have two examples below and I just wonder which of these is the best. As
you can see the sex is used as an attribute in one of the example and as an
element in the other.

Can you give a comment which is best and why ?

There's no good answer. In general, attributes are less flexible (they
cannot contain structured data that is exposed to XML parser, for
example). On the other hand, attributes are inherently unordered,
while elements are. You can treat your elements as unordered in
practice, but it can be hard to express in XML schema if you decide to
write one for your format (it has <xs:all>, but that doesn't allow you
to mix a bunch of unordered child elements with some ordered ones).

In .NET context specifically, attributes don't play well with
DataContractSerializer (read: WCF web services).

In general, from my past experience, if you want maximum
interoperability for your format, go for elements only. On the other
hand, if it's intended to be mostly read and edited by humans, then
you have to use your best judgement for each and every case (what
looks right, what looks wrong, etc).

A radical option is to go for XAML, which lets you use both forms
interchangeably. But that obviously complicates interop scenarios.

 

[Pavel Minaev]

This question has nothing to do with the actual C# language but .NET is very
tight connected with XML so I assume
many of you are very used to XML therefore I ask this question.
I have two examples below and I just wonder which of these is the best. As
you can see the sex is used as an attribute in one of the example and as an
element in the other.

Can you give a comment which is best and why ?

There's no good answer. In general, attributes are less flexible (they
cannot contain structured data that is exposed to XML parser, for
example). On the other hand, attributes are inherently unordered,
while elements are. You can treat your elements as unordered in
practice, but it can be hard to express in XML schema if you decide to
write one for your format (it has <xs:all>, but that doesn't allow you
to mix a bunch of unordered child elements with some ordered ones).

In .NET context specifically, attributes don't play well with
DataContractSerializer (read: WCF web services).

In general, from my past experience, if you want maximum
interoperability for your format, go for elements only. On the other
hand, if it's intended to be mostly read and edited by humans, then
you have to use your best judgement for each and every case (what
looks right, what looks wrong, etc).

A radical option is to go for XAML, which lets you use both forms
interchangeably. But that obviously complicates interop scenarios.

 

[Cor Ligthert[MVP]]

Tony,

The first one using the attributes would be the better one.

However, SQL based databases (not only SQL Server) are not able to handle
this complex data.

Therefore everything has to be separated in tables (elements) that is why
you see the latter version by instance in a serialized dataset.

Cor

 

[Cor Ligthert[MVP]]

Tony,

The first one using the attributes would be the better one.

However, SQL based databases (not only SQL Server) are not able to handle
this complex data.

Therefore everything has to be separated in tables (elements) that is why
you see the latter version by instance in a serialized dataset.

Cor

 

[Pavel Minaev]

The first one using the attributes would be the better one.

Is it just your personal taste (in which case it would be nice to
indicate it as such), or do you actually have specific reasons to
claim this?

However, SQL based databases (not only SQL Server) are not able to handle
this complex data.

This is wrong. I'm not sure what SQL databases in general even have to
do with XML data (???), but those of them that are XML-enabled - such
as, well, SQL Server with its XML datatype - can handle attributes
perfectly well, both in storage, and in queries.

Therefore everything has to be separated in tables (elements) that is why
you see the latter version by instance in a serialized dataset.

This is wrong, too. There's no connection between the format of
serialized dataset, and DMBS limitations. Serialized datasets are not
passed to DBMS.

 

[Pavel Minaev]

The first one using the attributes would be the better one.

Is it just your personal taste (in which case it would be nice to
indicate it as such), or do you actually have specific reasons to
claim this?

However, SQL based databases (not only SQL Server) are not able to handle
this complex data.

This is wrong. I'm not sure what SQL databases in general even have to
do with XML data (???), but those of them that are XML-enabled - such
as, well, SQL Server with its XML datatype - can handle attributes
perfectly well, both in storage, and in queries.

Therefore everything has to be separated in tables (elements) that is why
you see the latter version by instance in a serialized dataset.

This is wrong, too. There's no connection between the format of
serialized dataset, and DMBS limitations. Serialized datasets are not
passed to DBMS.

 

[sloan]

Pavel,

Looks like you're right....I was able to parse/shred the xml fairly quickly.
Even when its a mixture of attributes and elements.

--Sql Server 2005
DECLARE @data XML;

SET @data =

N'

<root>

<person sex="female">

<firstname>Anna</firstname>

<lastname>Smith</lastname>

</person>

<person sex="male">

<firstname>John</firstname>

<lastname>Jones</lastname>

</person>

</root>

';







-- Using the value() method

SELECT

T.customer.value('@sex', 'varchar(12)') AS gender,

T.customer.value('(firstname)[1]', 'varchar(12)') AS fname,

T.customer.value('(lastname)[1]', 'VARCHAR(20)') AS lastname

FROM @data.nodes('root/person') AS T(customer);



Special thanks to Plamen's article:
http://pratchev.blogspot.com/2007/06/shredding-xml-in-sql-server-2005.html

The first one using the attributes would be the better one.

Is it just your personal taste (in which case it would be nice to
indicate it as such), or do you actually have specific reasons to
claim this?

However, SQL based databases (not only SQL Server) are not able to handle
this complex data.

This is wrong. I'm not sure what SQL databases in general even have to
do with XML data (???), but those of them that are XML-enabled - such
as, well, SQL Server with its XML datatype - can handle attributes
perfectly well, both in storage, and in queries.

Therefore everything has to be separated in tables (elements) that is why
you see the latter version by instance in a serialized dataset.

This is wrong, too. There's no connection between the format of
serialized dataset, and DMBS limitations. Serialized datasets are not
passed to DBMS.

 

[sloan]

Pavel,

Looks like you're right....I was able to parse/shred the xml fairly quickly.
Even when its a mixture of attributes and elements.

--Sql Server 2005
DECLARE @data XML;

SET @data =

N'

<root>

<person sex="female">

<firstname>Anna</firstname>

<lastname>Smith</lastname>

</person>

<person sex="male">

<firstname>John</firstname>

<lastname>Jones</lastname>

</person>

</root>

';







-- Using the value() method

SELECT

T.customer.value('@sex', 'varchar(12)') AS gender,

T.customer.value('(firstname)[1]', 'varchar(12)') AS fname,

T.customer.value('(lastname)[1]', 'VARCHAR(20)') AS lastname

FROM @data.nodes('root/person') AS T(customer);



Special thanks to Plamen's article:
http://pratchev.blogspot.com/2007/06/shredding-xml-in-sql-server-2005.html

The first one using the attributes would be the better one.

Is it just your personal taste (in which case it would be nice to
indicate it as such), or do you actually have specific reasons to
claim this?

However, SQL based databases (not only SQL Server) are not able to handle
this complex data.

This is wrong. I'm not sure what SQL databases in general even have to
do with XML data (???), but those of them that are XML-enabled - such
as, well, SQL Server with its XML datatype - can handle attributes
perfectly well, both in storage, and in queries.

Therefore everything has to be separated in tables (elements) that is why
you see the latter version by instance in a serialized dataset.

This is wrong, too. There's no connection between the format of
serialized dataset, and DMBS limitations. Serialized datasets are not
passed to DBMS.

 

[Cor Ligthert[MVP]]

Sloan

Apples and pears

In that way, you tell that an image (data type) can give (direct) numeric
information.

It is about if an element is a data type itself in a database, not the XML
string.

Cor

Pavel,

Looks like you're right....I was able to parse/shred the xml fairly
quickly.
Even when its a mixture of attributes and elements.

--Sql Server 2005
DECLARE @data XML;

SET @data =

N'

<root>

<person sex="female">

<firstname>Anna</firstname>

<lastname>Smith</lastname>

</person>

<person sex="male">

<firstname>John</firstname>

<lastname>Jones</lastname>

</person>

</root>

';







-- Using the value() method

SELECT

T.customer.value('@sex', 'varchar(12)') AS gender,

T.customer.value('(firstname)[1]', 'varchar(12)') AS fname,

T.customer.value('(lastname)[1]', 'VARCHAR(20)') AS lastname

FROM @data.nodes('root/person') AS T(customer);



Special thanks to Plamen's article:
http://pratchev.blogspot.com/2007/06/shredding-xml-in-sql-server-2005.html

The first one using the attributes would be the better one.

Is it just your personal taste (in which case it would be nice to
indicate it as such), or do you actually have specific reasons to
claim this?

However, SQL based databases (not only SQL Server) are not able to handle
this complex data.

This is wrong. I'm not sure what SQL databases in general even have to
do with XML data (???), but those of them that are XML-enabled - such
as, well, SQL Server with its XML datatype - can handle attributes
perfectly well, both in storage, and in queries.

Therefore everything has to be separated in tables (elements) that is why
you see the latter version by instance in a serialized dataset.

This is wrong, too. There's no connection between the format of
serialized dataset, and DMBS limitations. Serialized datasets are not
passed to DBMS.

 

[Cor Ligthert[MVP]]

Sloan

Apples and pears

In that way, you tell that an image (data type) can give (direct) numeric
information.

It is about if an element is a data type itself in a database, not the XML
string.

Cor

Pavel,

Looks like you're right....I was able to parse/shred the xml fairly
quickly.
Even when its a mixture of attributes and elements.

--Sql Server 2005
DECLARE @data XML;

SET @data =

N'

<root>

<person sex="female">

<firstname>Anna</firstname>

<lastname>Smith</lastname>

</person>

<person sex="male">

<firstname>John</firstname>

<lastname>Jones</lastname>

</person>

</root>

';







-- Using the value() method

SELECT

T.customer.value('@sex', 'varchar(12)') AS gender,

T.customer.value('(firstname)[1]', 'varchar(12)') AS fname,

T.customer.value('(lastname)[1]', 'VARCHAR(20)') AS lastname

FROM @data.nodes('root/person') AS T(customer);



Special thanks to Plamen's article:
http://pratchev.blogspot.com/2007/06/shredding-xml-in-sql-server-2005.html

The first one using the attributes would be the better one.

Is it just your personal taste (in which case it would be nice to
indicate it as such), or do you actually have specific reasons to
claim this?

However, SQL based databases (not only SQL Server) are not able to handle
this complex data.

This is wrong. I'm not sure what SQL databases in general even have to
do with XML data (???), but those of them that are XML-enabled - such
as, well, SQL Server with its XML datatype - can handle attributes
perfectly well, both in storage, and in queries.

Therefore everything has to be separated in tables (elements) that is why
you see the latter version by instance in a serialized dataset.

This is wrong, too. There's no connection between the format of
serialized dataset, and DMBS limitations. Serialized datasets are not
passed to DBMS.

 

[Cor Ligthert[MVP]]

The first one using the attributes would be the better one.

Is it just your personal taste (in which case it would be nice to
indicate it as such), or do you actually have specific reasons to
claim this?

My personal taste is to use elements because I am forever working with
databases.
However, XML is not created with attributes without an intention.

This is wrong. I'm not sure what SQL databases in general even have to
do with XML data (???), but those of them that are XML-enabled - such
as, well, SQL Server with its XML datatype - can handle attributes
perfectly well, both in storage, and in queries.

See my reply to sloan

This is wrong, too. There's no connection between the format of
serialized dataset, and DMBS limitations. Serialized datasets are not
passed to DBMS.

See for this the reply to sloan, who says however that you are right,
strange way of replying but probably that you both are mixing up apples and
pears.

There is no connection between a dataset and a database at all.
A dataset is a dotNet OO wise representation of the relational model of a
SQL type Database (not based on the entities but on the relations).

For a SQL database a dataset is completely unknown, a SQL database returns a
result set.

Cor

 

[Cor Ligthert[MVP]]

The first one using the attributes would be the better one.

Is it just your personal taste (in which case it would be nice to
indicate it as such), or do you actually have specific reasons to
claim this?

My personal taste is to use elements because I am forever working with
databases.
However, XML is not created with attributes without an intention.

This is wrong. I'm not sure what SQL databases in general even have to
do with XML data (???), but those of them that are XML-enabled - such
as, well, SQL Server with its XML datatype - can handle attributes
perfectly well, both in storage, and in queries.

See my reply to sloan

This is wrong, too. There's no connection between the format of
serialized dataset, and DMBS limitations. Serialized datasets are not
passed to DBMS.

See for this the reply to sloan, who says however that you are right,
strange way of replying but probably that you both are mixing up apples and
pears.

There is no connection between a dataset and a database at all.
A dataset is a dotNet OO wise representation of the relational model of a
SQL type Database (not based on the entities but on the relations).

For a SQL database a dataset is completely unknown, a SQL database returns a
result set.

Cor

 

[Martin Maat]

I have two examples below and I just wonder which of these is the
best. As you can see the sex is used as an attribute in one of the
example and as an element in the other.

Can you give a comment which is best and why ?

<person sex="female">
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>

<person>
<sex>female</sex>
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>

The choice is yours and often one of personal taste but considering all
three sub-entities are properties of person, I would keep them in the same
domain: either use elements for all of them or attributes for all of them.

I prefer to use attribues for simple data like value types (strings,
numbers, dates, enumerations and such). I only use elements for complex data
(reference typed objects that may have sub-data). That way the XML structure
reflects your data model, it seems to me this is what it was meant to do and
that is why we have attributes. If you only use elements the XML becomes
very hard to read and doesn't "make sense".

Then again, I have no experience using XML with SQL Server, which may make
it convenient to use elements only for technical reasons.

Martin.

 

[Martin Maat]

I have two examples below and I just wonder which of these is the
best. As you can see the sex is used as an attribute in one of the
example and as an element in the other.

Can you give a comment which is best and why ?

<person sex="female">
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>

<person>
<sex>female</sex>
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>

The choice is yours and often one of personal taste but considering all
three sub-entities are properties of person, I would keep them in the same
domain: either use elements for all of them or attributes for all of them.

I prefer to use attribues for simple data like value types (strings,
numbers, dates, enumerations and such). I only use elements for complex data
(reference typed objects that may have sub-data). That way the XML structure
reflects your data model, it seems to me this is what it was meant to do and
that is why we have attributes. If you only use elements the XML becomes
very hard to read and doesn't "make sense".

Then again, I have no experience using XML with SQL Server, which may make
it convenient to use elements only for technical reasons.

Martin.