identically named attributes for one element

[Joris Gillis]

Hi everyone,

I was wondering...
Can one element have multiple (identically named) attributes in XML?
e.g. Is the following document valid XML?

<?xml version="1.0" encoding="UTF-8"?>
<root a="1" a="2" a="3"/>

And if it is, how can I create this document with XSLT when this is the input XML?
<?xml version="1.0" encoding="UTF-8"?>
<root>
<a>1</a>
<a>2</a>
<a>3</a>
</root>

It seems that the 'xsl:attribute' element overwrites each attribute (with the same name) that is already present in the result tree element.

Any reactions? Thanks in advance...

regards,

 

[Martin Honnen]

Joris Gillis wrote:

Can one element have multiple (identically named) attributes in XML?
No.

e.g. Is the following document valid XML?

<?xml version="1.0" encoding="UTF-8"?>
<root a="1" a="2" a="3"/>

Validity can only be checked against a DTD or schema thus your question
whether that is "valid" XML should rather be whether the above is
"well-formed" and the answer to that is no, it is not well-formed, see
<http://www.w3.org/TR/2004/REC-xml-20040204/#sec-starttags>
which says:

Well-formedness constraint: Unique Att Spec

An attribute name MUST NOT appear more than once in the same start-tag
or empty-element tag.

 

[Joris Gillis]

Thanks for your reaction.

No.

Validity can only be checked against a DTD or schema thus your question
whether that is "valid" XML should rather be whether the above is
"well-formed"

Thanks for pointing that out. I keep confusing those terms.

The answer to that is no, it is not well-formed, see
<http://www.w3.org/TR/2004/REC-xml-20040204/#sec-starttags>
which says:
Well-formedness constraint: Unique Att Spec

An attribute name MUST NOT appear more than once in the same start-tag
or empty-element tag.

Is there any chance of change regarding this rule in XML? Or is this a fundamental rule that directly reflects the very spirit of XML?


regards,

 

[Thomas Scheffler]

Thanks for your reaction.


So if I say that my XSLT processor (Altova) does not choke on a document
with such element and allows me to access all these attributes with
'<xsl:apply-templates select="@*"/>', then this means that the
software's behaviour is not conform the XML (and XSL) standard?

Yes, as the XML document itself is not wellformed it should not be
transformed then.

Is there any chance of change regarding this rule in XML? Or is this a
fundamental rule that directly reflects the very spirit of XML?

The "spirit" is that it is as simple and mighty subset of SGML and not
"we make all your dreams possible"-standard.

What you want is something like:
<ball kind="football" color="black" color="white" color="red"/>
What ever that means it can transformed in some kind of
<ball kind="spirit">
<color>black</color>
<color>white</color>
<color>red</color>
</ball>

An attribute is to describe an element. It just makes no sence to have
several attributes with the same name. As you can not ask the question
"Which color have the (some) ball of kind 'football'?"
Imagine you would answer for the question how old you are:
1st) 20
2nd) 37
3rd) 13

Hope you got the point.

Cheers

Thomas

 

[Joris Gillis]

Is there any chance of change regarding this rule in XML? Or is this a

The "spirit" is that it is as simple and mighty subset of SGML and not
"we make all your dreams possible"-standard.

It rather tends to that type of standard

So it's an inherited rule from SGML?

What you want is something like:
<ball kind="football" color="black" color="white" color="red"/>
What ever that means it can transformed in some kind of
<ball kind="spirit">
<color>black</color>
<color>white</color>
<color>red</color>
</ball>

An attribute is to describe an element. It just makes no sence to have
several attributes with the same name. As you can not ask the question
"Which color have the (some) ball of kind 'football'?"
Imagine you would answer for the question how old you are:
1st) 20
2nd) 37
3rd) 13

Yes, off course, it doesn't make sense in these situations, but someone might come op with a real-life use for it.

Quantum mechanincs maybe:
<box>
<cat state="dead" state="alive"/>
</box>
Okay, I'm just kidding


P.S. I came up with this thought from an XLST perspective.
(If <xsl:apply-templates select="color"/> works, why not <xsl:apply-templates select="@color"/> ?)

 

[Martin Honnen]

Joris Gillis wrote:

So if I say that my XSLT processor (Altova) does not choke on a document
with such element and allows me to access all these attributes with
'<xsl:apply-templates select="@*"/>', then this means that the
software's behaviour is not conform the XML (and XSL) standard?

In my view the XML parser used should raise an error that the parsed
source document is not well-formed when it encounters two attributes
with the same name inside the same tag.
As for XSL or XSLT that standard only speaks of transforming trees, how
the tree is constructed from a source document is not part of the
standard and thus I think it is hard to tell whether an input tree could
be constructed when the source document is not well-formed.

 

[Jan Roland Eriksson]

It rather tends to that type of standard

The "Hype Factor" stuffed into XML already from the start, as given by
several of those media guys who thought they had understood it all as...

"hey, this is cool, I can make up my own tags as I go"

....probably meant a great deal for the impact of XML on the public, as
compared to the level of knowledge and understanding that was spread
earlier for SGML.

But, at least I see from lots of posts here in this NG, today's crowd of
XML'ers are basically struggling with the same type of problems as
SGML'ers used to do back then

So it's an inherited rule from SGML?

You can say that; SGML requires all element attribute names to be unique
as given in an element start tag.

[...]

Quantum mechanics maybe:
<box>
<cat state="dead" state="alive"/>
</box>
Okay, I'm just kidding

Yea, I know you are

But seriously, just your markup snip here above happens to point to a
more common misunderstanding in how to build a markup model that works.

Attributes are not supposed to describe a characteristic part of the
start tag where they happen to live, but instead they are supposed to
describe a characteristic part of the element content that is delimited
by the start and end tag of the element as a whole.

Which means that you can/shall not assign content characteristic
attributes to an "empty" element since such an element does not have any
content in the first place, right?

"cat" in an element start tag must be possible to be recognized as a
noun. Your "cat" markup is treating the element name as if it was an
adjective that needs to be assigned a "value", as in...

<cat breed="Siamese" breed="Burma"/>

....it can just not be made to work in practice

All the best...

 

[Joris Gillis]

a more common misunderstanding in how to build a markup model that works.

Attributes are not supposed to describe a characteristic part of the
start tag where they happen to live, but instead they are supposed to
describe a characteristic part of the element content that is delimited
by the start and end tag of the element as a whole.

Really? Then there's something fundamentally wrong with my interpretation of 'markup', if I ever had one... I never had the opportunity to read any book on the subject.
I always assumed that attributes describe a characteristic part of the element (not the element's content).

Thanks for your valuable reaction.

Med bästa hälsningar,

 

[Joris Gillis]

So if I say that my XSLT processor (Altova) does not choke on a document

In my view the XML parser used should raise an error that the parsed
source document is not well-formed when it encounters two attributes
with the same name inside the same tag.
As for XSL or XSLT that standard only speaks of transforming trees, how
the tree is constructed from a source document is not part of the
standard and thus I think it is hard to tell whether an input tree could
be constructed when the source document is not well-formed.

What a remarkable insight you have in these matters... You could be a member of a working group at W3C's (or another consortium)

 

[Jan Roland Eriksson]

(and I was correct up to about here, and then went on to "flunk" my
words)

... but instead they are supposed to describe a characteristic part
of the element content that is delimited by the start and end tag of
the element as a whole.

[...]

I always assumed that attributes describe a characteristic part of the
element (not the element's content).

Yep, you are correct on that part, sorry for the confusion.

I will refrain from pulling up yet another discussion on where to define
attributes versus elements. The available reading material on that
subject is already as big as it ever needs to be

Still it's my view that markup attributes should be defined sparingly,
many times it is possible to define more simple elements instead, to
achieve the same end result.

Even more to the point, lots of times I keep thinking that empty
elements might be better included in marked up source as processing
instructions.

In your previous example, the "more simple elements" approach would
provide an alternative solution to your initial "problem" for this
thread, e.g.

Instead of,

<cat status="dead" status="alive"/>

why not?

<animal>
<type>cat</type>
<status>dead</status>
<status>alive</status>
<status> ...
</animal>

Given a correct set of semantic definitions and syntax declarations for
the above markup you could be at liberty to include as many different
valid variations of dead, alive and anything in between, as you like.

Med bästa hälsningar,

Jag får önska god fortsättning på det nya året