InfoPath Dev

When should i use a Field Attribute instead of a Field Element?

There is not set pattern on this. Each has its benefits.

The one thing to keep in mind is that for attributes, if you choose a datatype other than string, it automatically becomes a required field. If you want to have a "date" attribute, but not required, you must use a string--but then you lose the automatic datatype validation that InfoPath provides.

For me, I like to use attributes when they are more tightly related to a particular element. And I often like to use them on repeating elements because it makes the list easier to read in the XML itself (if your into looking at the raw XML).

Greg, thanks. I accidently added a field attribute and it took me a while to realize why it was required and I could not change it, which is why I asked this question. Do you have any examples of business scenarios in which "attributes are tightly related to a particular element"? I'm not quite sure what you mean by this.
Thanks

Its always arguable which to use. It really comes down to policy and preference.

For example, I might use an attribute like this:

<Product id="12345">
    <ProductDetail_1/>
    <ProductDetail_2/>
</Product>

But someone else might recommend:

<Product>
    <Id>12345</Id>
    <ProductDetail_1/>
    <ProductDetail_2/>
</Product>

Which is right? Both.

For a repeating group, I might like something like this because it makes it cleaner in the XML:

<Vehicle vin="" color="" engineType="" etc=""/>

Whereas someone else might prefer the following because each element is easier to find:

<Vehicle>
    <Vin/>
    <Color/>
    <EngineType/>
    <Etc/>
</Vehicle>

Which is right? Again, both.

It all comes down to either policy or personal preference.