=?UTF-8?Q?Re=3A_=5Bxml=2Ddev=5D_Don=E2=80=99t_create_elements_with

There has been a substantial international effort in exactly this issue which has resulted in widely adopted boutique standards for financial reporting: XBRL.

In XBRL, you have "facts" like a number. But every number must have units, in particular currency, otherwise it is meaningless; and notation info too (eg number of elided decimal places.) Furthermore, each fact needs a context, such as who says, the reporting period, rubberyness, accounting basis, etc.

In XBRL, facts are element values, units/places are attributes, and contexts are attribute refences to context declarations.

What is the rationale? The unit and notation dara are attributes because the intent is that this information must never be disconnected from the fact. It is not severable, the way that, say, parallel elements would be. The context is marked up with context references, because they can be shared (and context in turn are divided and grouped into dimensions.)

What is the pattern? XNL syntax provides four levels of differentiation: element names, attributes, reference attributes and container names. (PIs are available, too, but only Schematron gives them first class support.) Any sensible schema matches these four available levels with the primary analytical categories required by the document.

In other words, a question like "when do we use attributes?" is quite mistaken: the question is first "what are the most important rival analytical categories for our data?" , and then "how do we divvie up these categories into the four available kinds of markup to maximise cohesion and coupling (or some other pragmatic metric, based on a theory if how the document will be used, technology and above all human clarity.) You cannot judge appropriateness of one markup or another in abstesct terms, only in context of the analytical categories of the schema and some theory of usage/usability/metrics appropriate for that schrma.

So you would need to take a schema wide view, not an individual element view. The problem set up needs to include, for example, "I am sending around documents of costs around the world, with no other information, and the costs are all normalized against the local hamburger price at MacDonalds, and the data must be trivially imported into a spreadsheet without xslt and will not be read by people interested in keeping related information together."

XBRL instances are exemplorary in this regard (despite XBRL's monstrous declaration), that the syntax usage clearly follows clear analytical categories.

Regards

Rick

On Sat, 29 Sep. 2018, 00:49 Costello, Roger L., <costello@mitre.org> wrote:

Hi Folks,

Thank you for the excellent replies.

Based on the replies, I see that I did a poor job explaining my position. Let me try again, please.

I am not arguing against attributes.

I am arguing against unlabeled data.

All of the following forms are good because they explicitly label the two pieces of data (USD and 8.95):

<Cost>
    <Currency>USD</Currency>
    <Amount>8.95</Amount>
</Cost>

<Cost currency="USD" amount="8.95" />

<Cost currency="USD">
    <Amount>8.95</Amount>
</Cost>

<Cost amount="8.95">
    <Currency>USD</Currency>
</Cost>

It matters not whether the label is in the form of an attribute or an element.

I am arguing that the following is bad because one piece of data (8.95) is not explicitly labeled:

<Cost currency="USD">8.95</Cost>

You might argue that 8.95 is labeled and the label is Cost. I disagree. I argue that Cost applies to the entire element (including the currency attribute); it does not specifically apply to 8.95.

As a result of the absence of an explicit label for 8.95, it is impossible to convert that form to an element-only form without human intervention. For example, a couple days ago one human suggested that 8.95 be labeled with “Amount” like so:

<Cost>
    <Currency>USD</Currency>
    <Amount>8.95</Amount>
</Cost>

This need to get humans involved to convert to an element-only form is bad, I argue.

Comments?

/Roger