XML attribute vs XML element

Question

At work we are being asked to create XML files to pass data to another offline application that will then create a second XML file to pass back in order to update some of our data. During the process we have been discussing with the team of the other application about the structure of the XML file.

The sample I came up with is essentially something like:

<INVENTORY> <ITEM serialNumber="something" location="something" barcode="something"> <TYPE modelNumber="something" vendor="something"/> </ITEM> </INVENTORY>

The other team said that this was not industry standard and that attributes should only be used for Meta data. They suggested:

<INVENTORY> <ITEM> <SERIALNUMBER>something</SERIALNUMBER> <LOCATION>something</LOCATION> <BARCODE>something</BARCODE> <TYPE> <MODELNUMBER>something</MODELNUMBER> <VENDOR>something</VENDOR> </TYPE> </ITEM> </INVENTORY>

The reason I suggested the first is that the size of the file created is much smaller. There will be roughly 80000 items that will be in the file during transfer. There suggestion in reality turns out to be three times larger than the one I suggested. I searched for the mysterIoUs "Industry Standard" that was mentioned but the closest I could find was the XML attributes should only be used for Meta data,but said the debate was about what was actually Meta data.

After the long winded explanation (sorry) how do you determine what is Meta data,and when designing the structure of an XML document how should you decide when to use an attribute or an element?

I found this really good resource: ibm.com/developerworks/xml/library/x-eleatt.html — Sep 27 '10 at 10:59
+1 for "...the debate was about what was actually Meta data." — Jul 24 '13 at 14:00
Please note lowercase tag names with hyphens : stackoverflow.com/questions/1074447/… — Mar 8 '15 at 17:04

CMircea · Accepted Answer · 2011-08-29 13:14:48Z

up vote 109 down vote accepted

I use this rule of thumb:

An Attribute is something that is self-contained,i.e.,a color,an ID,a name.
An Element is something that does or could have attributes of its own or contain other elements.

So yours is close. I would have done something like:

EDIT: Updated the original example based on Feedback below.

 <ITEM serialNumber="something"> <BARCODE encoding="Code39">something</BARCODE> <LOCATION>XYX</LOCATION> <TYPE modelNumber="something"> <VENDOR>YYZ</VENDOR> </TYPE> </ITEM>

edited Aug 29 '11 at 13:14

CMircea

2,401 2 26 47

answered Aug 29 '08 at 1:28

Chuck

12.4k 3 22 48

19

I read through some of the answers and something that wasn't stressed enough form my experience is that if you data in an "attribute" and suddenly has a > or < you XML document will break I think there are five ascii chars (>,<,&,?,") that will kill it. If this special character was in an Element you can simply add some CDATA tags around this data. I would say,only use attributes when you 100% know what values are going to put in there,eg,a integer or a date,probably anything that is computer generated. If the BarCode was generated by a human then it should not be an attribute. – John Ballinger Jul 5 '09 at 12:06

29

Really late to the party,but the special ASCII char argument is wrong -- that's what escaping is for,both for attributes and text data. – micahtan Nov 25 '09 at 4:11

1

@donroby - Sorry,that would be my mistake in communicating. By escaping,I mean XML encoding. '<' = < etc. It seems odd to me to decide between an attribute or element based on the characters that make up the content instead of the meaning of the content. – micahtan May 17 '10 at 21:29

2

@donroby: it's incorrect. The replacement text of < is <,which is a character reference,not an entity reference. < is OK in attributes. See: w3.org/TR/REC-xml/#sec-predefined-ent – porges Jun 24 '10 at 4:10

11

@John: if this is a problem then there's something in your toolchain which isn't producing valid XML. I don't think this is a reason to choose between attributes or elements. (Furthermore,you can't "just add CDATA tags" around user-input because it might contain ]]>!) – porges Jun 24 '10 at 4:13

show 8 more comments

Rahul Maurya · Answer 2 · 2016-07-25 07:37:37Z

up vote 34 down vote

Some of the problems with attributes are:

attributes cannot contain multiple values (child elements can)
attributes are not easily expandable (for future changes)
attributes cannot describe structures (child elements can)
attributes are more difficult to manipulate by program code
attribute values are not easy to test against a DTD

If you use attributes as containers for data,you end up with documents that are difficult to read and maintain. Try to use elements to describe data. Use attributes only to provide information that is not relevant to the data.

Don't end up like this (this is not how XML should be used):

<note day="12" month="11" year="2002" to="Tove" from="Jani" heading="Reminder" body="Don't forget me this weekend!"> </note>

Source: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

edited Jul 25 at 7:37

Rahul Maurya

73 4

answered Jan 7 '09 at 12:49

user44350

349 4 4

1

First point is incorrect,see: w3.org/TR/xmlschema-2/#derivation-by-list – porges Jun 27 '10 at 23:31

6

I'd say that first point is correct and list is a partial workaround to this problem. There can't be multiple attributes with same name. With list attribute still has only one value,which is a whitespace separated list of some datatypes. Separation characters are fixed so you cannot have multiple values if a single value of the wanted datatype can contain whitespace. This rules out the chances for having for example multiple addresses in one "address" attribute. – jasso Sep 5 '10 at 1:49

5

'attributes are more difficult to manipulate by program code' - Can't agree with that one. In fact I've found the opposite to be true. It's not enough of a difference to really state either way. – Paul Alexander Mar 8 '12 at 23:19

2

I'd also add that validation against a DTD isn't really relevant anymore,with XML-Schema,Schematron and Relax,et. al. all providing vastly more powerful and in some cases more intuitive ways of validating XML documents. Also, W3Schools is a really poor reference for anything – Lego Stormtroopr May 16 '13 at 1:34

add a comment

dan04 · Answer 3 · 2010-06-24 04:02:05Z

"XML" stands for "eXtensible Markup Language". A markup language implies that the data is text,marked up with Metadata about structure or formatting.

XHTML is an example of XML used the way it was intended:

<p><span lang="es">El Jefe</span> insists that you <em class="urgent">MUST</em> complete your project by Friday.</p>

Here,the distinction between elements and attributes is clear. Text elements are displayed in the browser,and attributes are instructions about how to display them (although there are a few tags that don't work that way).

Confusion arises when XML is used not as a markup language,but as a data serialization language,in which the distinction between "data" and "Metadata" is more vague. So the choice between elements and attributes is more-or-less arbitrary except for things that can't be represented with attributes (see feenster's answer).

kjhughes · Answer 4 · 2014-04-17 12:56:33Z

XML Element vs XML Attribute

XML is all about agreement. First defer to any existing XML schemas or established conventions within your community or industry.

If you are truly in a situation to define your schema from the ground up,here are some general considerations that should inform the element vs attribute decision:

<versus> <element attribute="Meta content"> Content </element> <element attribute="Flat"> <parent> <child>Hierarchical</child> </parent> </element> <element attribute="Unordered"> <ol> <li>Has</li> <li>order</li> </ol> </element> <element attribute="Must copy to reuse"> Can reference to re-use </element> <element attribute="For software"> For humans </element> <element attribute="Extreme use leads to micro-parsing"> Extreme use leads to document bloat </element> <element attribute="Unique names"> Unique or non-unique names </element> <element attribute="SAX parse: read first"> SAX parse: read later </element> <element attribute="DTD: default value"> DTD: no default value </element> </versus>

AnthonyWJones · Answer 5 · 2008-09-30 10:24:12Z

It may depend on your usage. XML that is used to represent stuctured data generated from a database may work well with ultimately field values being placed as attributes.

However XML used as a message transport would often be better using more elements.

For example lets say we had this XML as proposed in the answer:-

<INVENTORY> <ITEM serialNumber="something" barcode="something"> <Location>XYX</LOCATION> <TYPE modelNumber="something"> <VENDOR>YYZ</VENDOR> </TYPE> </ITEM> </INVENTORY>

Now we want to send the ITEM element to a device to print he barcode however there is a choice of encoding types. How do we represent the encoding type required? Suddenly we realise,somewhat belatedly,that the barcode wasn't a single automic value but rather it may be qualified with the encoding required when printed.

 <ITEM serialNumber="something"> <barcode encoding="Code39">something</barcode> <Location>XYX</LOCATION> <TYPE modelNumber="something"> <VENDOR>YYZ</VENDOR> </TYPE> </ITEM>

The point is unless you building some kind of XSD or DTD along with a namespace to fix the structure in stone,you may be best served leaving your options open.

IMO XML is at its most useful when it can be flexed without breaking existing code using it.

Good point on the "barcode",I rushed my example and would have definitely broken that out into its own element. Also good point on the XSD/DTD. — Feb 23 '09 at 21:26

Archimedes Trajano · Answer 6 · 2010-12-16 08:06:37Z

I use the following guidelines in my schema design with regards to attributes vs. elements:

Use elements for long running text (usually those of string ornormalizedString types)
Do not use an attribute if there is grouping of two values (e.g.eventStartDate and eventEndDate) for an element. In the prevIoUs example,there should be a new element for "event" which may contain the startDate andendDate attributes.
Business Date,DateTime and numbers (e.g. counts,amount and rate) should beelements.
Non-business time elements such as last updated,expires on should beattributes.
Non-business numbers such as hash codes and indices should be attributes.* Use elements if the type will be complex.
Use attributes if the value is a simple type and does not repeat.
xml:id and xml:lang must be attributes referencing the XML schema
Prefer attributes when technically possible.

The preference for attributes is it provides the following:

unique (the attribute cannot appear multiple times)
order does not matter
the above properties are inheritable (this is something that the "all" content model does not support in the current schema language)
bonus is they are less verbose and use up less bandwidth,but that's not really a reason to prefer attributes over elements.

I added when technically possible because there are times where the use of attributes are not possible. For example,attribute set choices. For example use (startDate and endDate) xor (startTS and endTS) is not possible with the current schema language

If XML Schema starts allowing the "all" content model to be restricted or extended then I would probably drop it

Luke · Answer 7 · 2008-08-29 01:27:43Z

When in doubt, KISS -- why mix attributes and elements when you don't have a clear reason to use attributes. If you later decide to define an XSD,that will end up being cleaner as well. Then if you even later decide to generate a class structure from your XSD,that will be simpler as well.

Adam · Answer 8 · 2008-08-29 01:24:43Z

the million dollar question!

first off,don't worry too much about performance now. you will be amazed at how quickly an optimized xml parser will rip through your xml. more importantly,what is your design for the future: as the XML evolves,how will you maintain loose coupling and interoperability?

more concretely,you can make the content model of an element more complex but it's harder to extend an attribute.

erickson · Answer 9 · 2008-08-29 01:26:57Z

It is arguable either way,but your colleagues are right in the sense that the XML should be used for "markup" or Meta-data around the actual data. For your part,you are right in that it's sometimes hard to decide where the line between Meta-data and data is when modeling your domain in XML. In practice,what I do is pretend that anything in the markup is hidden,and only the data outside the markup is readable. Does the document make some sense in that way?

XML is notorIoUsly bulky. For transport and storage,compression is highly recommended if you can afford the processing power. XML compresses well,sometimes phenomenally well,because of its repetitiveness. I've had large files compress to less than 5% of their original size.

Another point to bolster your position is that while the other team is arguing about style (in that most XML tools will handle an all-attribute document just as easily as an all-#PCDATA document) you are arguing practicalities. While style can't be totally ignored,technical merits should carry more weight.

Michael J · Answer 10 · 2009-01-15 19:22:35Z

Use elements for data and attributes for Meta data (data about the element's data).

If an element is showing up as a predicate in your select strings,you have a good sign that it should be an attribute. Likewise if an attribute never is used as a predicate,then maybe it is not useful Meta data.

Remember that XML is supposed to be machine readable not human readable and for large documents XML compresses very well.

Patrick · Answer 11 · 2009-11-10 17:11:34Z

up vote 4 down vote

Others have covered how to differentiate between attributes from elements but from a more general perspective putting everything in attributes because it makes the resulting XML smaller is wrong.

XML is not designed to be compact but to be portable and human readable. If you want to decrease the size of the data in transit then use something else (such as google's protocol buffers).

edited Nov 10 '09 at 17:11

answered Nov 10 '09 at 16:43

Patrick

4,669 3 31 63

Or leave it as XML and use something like EXI (w3.org/TR/exi). – james.garriss Apr 3 '12 at 14:26

add a comment

rpattabi · Answer 12 · 2011-02-09 13:08:51Z

How about taking advantage of our hard earned object orientation intuition? I usually find it is straight forward to think which is an object and which is an attribute of the object or which object it is referring to.

Whichever intuitively make sense as objects shall fit in as elements. Its attributes (or properties) would be attributes for these elements in xml or child element with attribute.

I think for simpler cases like in the example object orientation analogy works okay to figure out which is element and which is attribute of an element.

aku · Answer 13 · 2008-08-29 01:29:49Z

Both methods for storing object's properties are perfectly valid. You should depart from pragmatic considerations. Try answering following question:

Which representation leads to faster data parsing\generation?
Which representation leads to faster data transfer?
Does readability matter?

...

Rory Becker · Answer 14 · 2008-09-30 09:23:18Z

It's largely a matter of preference. I use Elements for grouping and attributes for data where possible as I see this as more compact than the alternative.

For example I prefer.....

<?xml version="1.0" encoding="utf-8"?> <data> <people> <person name="Rory" surname="Becker" age="30" /> <person name="Travis" surname="Illig" age="32" /> <person name="Scott" surname="Hanselman" age="34" /> </people> </data>

...Instead of....

<?xml version="1.0" encoding="utf-8"?> <data> <people> <person> <name>Rory</name> <surname>Becker</surname> <age>30</age> </person> <person> <name>Travis</name> <surname>Illig</surname> <age>32</age> </person> <person> <name>Scott</name> <surname>Hanselman</surname> <age>34</age> </person> </people> </data>

However if I have data which does not represent easily inside of say 20-30 characters or contains many quotes or other characters that need escaping then I'd say it's time to break out the elements... possibly with CData blocks.

<?xml version="1.0" encoding="utf-8"?> <data> <people> <person name="Rory" surname="Becker" age="30" > <comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment> </person> <person name="Travis" surname="Illig" age="32" > <comment>A cool guy for who has helped me out with all sorts of SVn information</comment> </person> <person name="Scott" surname="Hanselman" age="34" > <comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment> </person> </people> </data>

This is flat wrong I'm afraid - you should follow W3C guidelines: w3schools.com/DTD/dtd_el_vs_attr.asp - XML should not be formed on readability or on making it "compact" - but rather using elements or attributes correctly for the purpose which they were designed for. — Jan 7 '09 at 12:59
I'm sorry,but this is misleading. The W3schools page is not W3C guidleines. The W3C XML recommendation (in which I was a participant) allows elements and attributes to be used according to the needs and styles of the users. — Jul 5 '09 at 11:45

Walter A. Jablonowski · Answer 15 · 2011-08-31 02:44:50Z

This is very clear in HTML where the differences of attributes and markup can be clearly seen:

All data is between markup
Attributes are used to characterize this data (e.g. formats)

If you just have pure data as XML,there is a less clear difference. Data could stand between markup or as attributes.

=> Most data should stand between markup.

If you want to use attributes here: You could divide data into two categories: Data and "Meta data",where Meta data is not part of the record,you want to present,but things like "format version","created date",etc.

<customer format=""> <name></name> ... </customer>

One could also say: "Use attributes to characterize the tag,use tags to provide data itself."

MGrier · Answer 16 · 2015-05-15 17:12:14Z

I am always surprised by the results of these kinds of discussions. To me there is a very simple rule for deciding whether data belongs in an attribute or as content and that is whether the data has navigable sub-structure.

So for example,non-markup text always belongs in attributes. Always.

Lists belong in sub-structure or content. Text which may over time include embedded structured sub-content belong in content. (In my experience there is relatively little of this - text with markup - when using XML for data storage or exchange.)

XML schema written this way is concise.

Whenever I see cases like <car><make>Ford</make><color>Red</color></car>,I think to myself "gee did the author think that there were going to be sub-elements within the make element?" <car make="Ford" color="Red" /> is significantly more readable,there's no question about how whitespace would be handled etc.

Given just but the whitespace handling rules,I believe this was the clear intent of the XML designers.

ottodidakt · Answer 17 · 2009-04-07 06:22:09Z

I agree with feenster. Stay away from attributes if you can. Elements are evolution friendly and more interoperable between web service toolkits. You'd never find these toolkits serializing your request/response messages using attributes. This also makes sense since our messages are data (not Metadata) for a web service toolkit.

oh pot · Answer 18 · 2011-04-08 19:51:46Z

Attributes can easily become difficult to manage over time trust me. i always stay away from them personally. Elements are far more explicit and readable/usable by both parsers and users.

Only time i've ever used them was to define the file extension of an asset url:

<image type="gif">wank.jpg</image> ...etc etc

i guess if you know 100% the attribute will not need to be expanded you could use them,but how many times do you know that.

<image> <url>wank.jpg</url> <fileType>gif</fileType> </image>

XML attribute vs XML element

XML attribute vs XML element

20 Answers

XML Element vs XML Attribute

猜你在找的XML相关文章