> The comma separated list of name=value is extensible but verbose. If we
> limit the information carried in attribute values to be only the number
> of occurrences and the type, we can simplify it to:
>
> <foo bar="?, xsd:integer"/>
>
> or, if we want to draw the attention to the fact that this value has a
> special meaning, we can add some kind of brackets such as:
>
> <foo bar="{?, xsd:integer}"/>
The things about this I don't like are:
- the ? inside the attribute value: the ? conceptually applies to the
entire attribute not merely the value
- very non-uniform with elements (although some non-uniformity seems
unavoidable)
- attribute value with complex structure; generally I prefer attributes
that don't require too much microparsing
Perhaps the best would be to say that literal attributes are always
optional. For required attributes, you have to use an element (i.e.
eg:attribute), but the default for such an element would be that the
attribute is required (as in RELAX NG). My thinking is that
- most of the time attributes are optional
- element syntax for attributes is least painful when the attribute is
required
In this case, the value of a literal attribute would just specify the
allowed value, not whether it was required/optional. Here, one could
follow the compact syntax and say that a name with a prefix refers to a
builtin datatype and a name without a prefix refers to a definition.
For example,
<foo bar="xsd:int"/>
turns into
element foo { attribute bar { xsd:int }? }
and
<foo bar="number"/>
turns into
element foo { attribute bar { number }? }
For elements, we could have an eg:type attribute that allows a name with
the same interpretation as the value of a literal attribute. For example,
<foo eg:type="xsd:int"/>
turns into
element foo { xsd:int }
and
<foo eg:type="number"/>
turns into
element foo { number }
James
