Can't duplicate any field names in XML?

[Guest]

Given an XML file (dataset.writexml), here is my output (simplified for this
posting):

<?xml version="1.0" standalone="yes"?>
<NewDataSet>
<Category>
<CategoryId>80</CategoryId>
<Category>MyCat</Category>
</Category>
</NewDataSet>

But when I debug the field names, I see that my app is tweaking the field
names, apparently because they are dupes (?).

?ds.Tables(0).TableName
"Category"
?ds.Tables(0).Columns(0).ColumnName
"CategoryId"
?ds.Tables(0).Columns(1).ColumnName
"Category_Id"

Am I not allowed to duplicate field and/or table names?

Looks like because my table is named "Category", that I can't also have
field named "Category".

If so, then I can't have an easy translation from SQL Server (PK/FK similar
field names) to XML. I guess I have to tweak my field names before writing
to XML? How should I go about doing this, or am I getting something wrong.

Thx.

 

[John Saunders [MVP]]

Given an XML file (dataset.writexml), here is my output (simplified for
this posting):

<?xml version="1.0" standalone="yes"?>
<NewDataSet>
<Category>
<CategoryId>80</CategoryId>
<Category>MyCat</Category>
</Category>
</NewDataSet>

But when I debug the field names, I see that my app is tweaking the field
names, apparently because they are dupes (?).

?ds.Tables(0).TableName
"Category"
?ds.Tables(0).Columns(0).ColumnName
"CategoryId"
?ds.Tables(0).Columns(1).ColumnName
"Category_Id"

Am I not allowed to duplicate field and/or table names?

Looks like because my table is named "Category", that I can't also have
field named "Category".

If so, then I can't have an easy translation from SQL Server (PK/FK
similar field names) to XML. I guess I have to tweak my field names before
writing to XML? How should I go about doing this, or am I getting
something wrong.

I'd say that what you got "wrong" is that you misuse the concept of a name.
I always say to name a thing for what it is, which implies that things with
the same name should be the same thing. Clearly, your "Category" field is
not the same as your "Category" table. Perhaps your "Category" field would
better be named "CategoryName". It will presumably be a unique field.

 

[Guest]

In a relational database, it's not uncommon to name an attribute the same as
the entity when applied to the physical world.

Category, which is an entity, has a similarly-named attrbute.

CATEGORY
CategoryID
Category

This concept, in the XML world, fails, right?

I'm asking for supporting evidence from people who know better than my
cursory experience, which seems to suggest that.

That you attacked my physical implementation doesn't address my question,
nor does it seem to get around the fact that this appears to be a strong
limitation to XML. Unless there's a way around that. If so, I'd like to know
how.

Also, you don't know that I'm responsible to create the database. For all
you know, someone else may have implemented this, and I'm just working
around that. Either way, you have decided to attack me.

MVP? What does that stand for? Most Vile Pinhead?

(No offense intended to other MVPs who go out of their way to help people.
Guess you're just having a bad day).

 

[John Saunders [MVP]]

In a relational database, it's not uncommon to name an attribute the same
as the entity when applied to the physical world.

Category, which is an entity, has a similarly-named attrbute.

CATEGORY
CategoryID
Category

This concept, in the XML world, fails, right?

I'm asking for supporting evidence from people who know better than my
cursory experience, which seems to suggest that.

That you attacked my physical implementation doesn't address my question,
nor does it seem to get around the fact that this appears to be a strong
limitation to XML. Unless there's a way around that. If so, I'd like to
know how.

Also, you don't know that I'm responsible to create the database. For all
you know, someone else may have implemented this, and I'm just working
around that. Either way, you have decided to attack me.

MVP? What does that stand for? Most Vile Pinhead?

(No offense intended to other MVPs who go out of their way to help people.
Guess you're just having a bad day).

You asked me what you had gotten "wrong", so I put my reply in those terms.
I'm aware that occasionally the entity is named the same as a piece of it -
I've done database work since before relational databases - and I stick to
my contention that two things should have the same name only if they are the
same thing. And the attribute isn't "similarly-named", it is identically
named, suggesting that it is (impossibly) the identical thing.

I _do_ prefer to distinguish between the entity, it's primary key (ID), a
textual equivalent to the primary key (Name) and a textual description. If
the naming were left to me, there would be a Category table, with CategoryID
as its primary key, with CategoryName as a unique field, and with
CategoryDescription as a non-unique, longer text description. This would
make all of the relationships clear, instead of saving four characters in a
column name by omitting "Name".

I responded with such a "philosophical" or "stylistic" response because I
believe that your practical problem is related to the stylistic one - in the
same way as the naming of this database would confuse human readers, I
believe that you have confused the software! Both problems would be
alleviated by giving a distinct name to the entity and to each of its
fields.

Now, you've got a very similar problem in your XML. It seems that you want
to have one element named "Category" which is of a complex type containing a
CategoryID and a Category, yet that second Category is meant to be of a
different type that the root "Category". Again, this is the result of giving
the same name to different things, and will only cause trouble. In this
case, you would need to convince software that, although these two elements
have the same name, they are actually unrelated (except for the name). Why,
for instance, should software not expect the following XML:

<Category>
<CategoryID>1</CategoryID>
<Category>
<CategoryID>2</Category>
<Category>....

So, frankly, it's not a problem with the XML world, nor a benefit that the
relational world has - it's just a matter of the fact that the naming
convention you were using (whether or not you are responsible for creating
it) is confusing to both humans and to software. Correcting the naming issue
would solve the problem both for humans and for XML, and would prevent this
from becoming a problem with the next piece of software which assumes that
names mean something.

 

[KJ]

XML names are case-sensitive, so CATEGORY is not the same as Category.
Simply change the column aliases in your SELECT statements to something
unique -- the aliases will become the XML names and your collisions will be
resolved.

In a relational database, it's not uncommon to name an attribute the same
as the entity when applied to the physical world.

Category, which is an entity, has a similarly-named attrbute.

CATEGORY
CategoryID
Category

This concept, in the XML world, fails, right?

I'm asking for supporting evidence from people who know better than my
cursory experience, which seems to suggest that.

That you attacked my physical implementation doesn't address my question,
nor does it seem to get around the fact that this appears to be a strong
limitation to XML. Unless there's a way around that. If so, I'd like to
know how.

Also, you don't know that I'm responsible to create the database. For all
you know, someone else may have implemented this, and I'm just working
around that. Either way, you have decided to attack me.

MVP? What does that stand for? Most Vile Pinhead?

(No offense intended to other MVPs who go out of their way to help people.
Guess you're just having a bad day).