intertwingly

<feed>
<generator>
<name>Movable Type</name>
<version>2.64</version>
<canonical-url>http://www.movabletype.org/</canonical-url>
<version-url>http://www.movabletype.org/?v=2.64</version-url>
</generator>
</feed>

Guan's example is why I prefer exhibit b over exhibit a. It gives you a place for the stuff you forgot today and want to add tomorrow.

I'm not fond of A, not because it uses attributes, but because it doesn't go whole hog. I say, pick attribute-normal or element-normal, but don't mix.

So my A would be:

<feed>
  <generator name="Movable Type" url="http://www.movabletype.org/?v=2.64" />
</feed>

You lose some type flexibility using A, in trade-off for XML that is (in my mind) easier to read and lighter on the wire.

After having put my thinking hat on for the last month over this, and similar issues - Exhibit B

If there is only ever one name and one url, they should be attributes. If there can be more than one, they should be elements.

Rorschach Test, that's pretty good. I see a little elephant dancing, not RDF.

Exhibit B is far more readable, and future extensible. And I'm sure the extra 20 characters or so won't damage aggregators, though we're not sure if they can handle the complexity of all that.

One word: whitespace.

<feed>
  <generator url="http://www.movabletype.org/?v=2.64" ...>
  ...
  </generator>
</feed>

I don't particularly care about what happens at the dots.

What is the purpose of this? Why should anyone care which software is generating a feed?

What it looks like on the wire is irrelevant.

Which one is easier to parse, with current or future tools?

They're both as easy to parse, and I like B better (as most people apparently do). Easier to extend. Consistent.

<feed>
  <generator
  name="Bob's Atom Smasher"
  uri="http://www.example.com/bob/smasher/1.0"
  />
</feed>

Exhibits A and B don't encode the same information.  In the first one, there's extra whitespace around the URI.  This does make a difference.

I've always considered that URIs and other such application-internal (as apposed to display) data are better off in attributes, leaving element content for stuff that you might actually want to display.

However, Atom already uses elements for nearly everything so changing from that now seems counter-intuitive.

http://www.movabletype.org/?v=2.64 is more like an ID than a URL, in the same sense as the entry ID element. For consistency with the rest of Atom, can't we call it 'id' and have a canonical URL (like the canonical URL for a person) using whatever element that uses?

Vote for (b) An Url within an attribute like (a) may be URL encoded AND XML encoded, that makes them very hard to read by a human

Which one is easier to parse, with current or future tools?

myGenName = myFeed.generator.xmlAttributes.name;

vs.

myGenName = myFeed.generator.name.xmlText;

Not a big difference to me either way.

Joe,

Correct me if I'm wrong, but isn't whitespace insignificant unless xml:space="preserve" is present?

Personally I think B is the better choice, for all the reasons already given.

Dave,

For some quick answers, you might want to read what Tim Bray says in the Annotated XML Specification (section 2.10 is on White Space Handling).

+1 for B, same reasons as others.

Dave:

isn'twhitespaceinsignificantunlessxml:space="preserve"ispresent?

Not exactly :-)

In the absense of an 'xml:space' attribute or with 'xml:space="default"', REC-xml says that "applications' default white-space processing modes are acceptable for this element".  It doesn't say anything further about what the "default whitespace processing modes" might be...

The intent of xml:space="preserve" is to account for things like the PRE element in HTML.  A web browser's "default whitespace processing mode" is to collapse consecutive spaces, tabs, and newlines into a single space;  inside a PRE element, however, linebreaks and indentation must be preserved.

So unless there is an application convention that says something like "in the default whitespace processing mode, leading and trailing whitespace shall be stripped from the content of all elements", the two exhibits above are different.

Joe and Dave,
The default behavior of an XML processor should be to act like the PRE element in HTML. An example of the effects of this behavior is in the following XML-DEV discussion thread at http://lists.xml.org/archives/xml-dev/200307/msg00868.html

I join the bandwagon for Exhibit B.

+1 4 B
(A is an ant planecrash)

When posted XML(from vb.net) is retrieved in ASP, it does not preserve spaces.
Can you please tell how to go about it?

No takers ?