"CRAWFORD, Mark" wrote <snipped>:
> >I wonder, though, if the draft proposal in this paper favors
> attributes too
> >heavily. With the advent of XSD, there is little you can do in
> attributes
> >that you can't do in elements -- even default values can be assigned
> to
> >elements that have a simple type. And even the code list case (which
> seems
> >like an obvious candidate for attributes because it often uses a
> closed set
> >of values) isn't crystal clear, because we know we need to add all
> kinds of
> >metadata and mechanisms to code lists to make them work.
>
> My position on this is use attributes only for document level
> information. This means that for the most part only built-in document
> level attributes such as xml:lang, id and idref should be used and
> elements should be used for all other transmitted data. My
> understanding is there are parsing, ordering, and performance issues
> surrounded with attributes. I also believe that by enforcing
> attributes at the document level, we will provide clarity, avoid
> confusion, and enable better structuring.
FYI - The X12 work has a consensus that matches Mark's position, though
we do have one strong dissenter.
> >Finally, I wonder if this paper can be expanded to explore the
> question of
> >empty elements too. This topic came up in the F2F last week (are
> empty
> >elements "leaf nodes"? should they be used only as "attribute
> hangers" or
> >also as presence/absence boolean indicators? how should we name them?
>
> >should we allow them at all?).
>
> Most strongly disagree with the concept of using empty elements as
> "attribute hangers" and "Boolean indicators".
Me too.
--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com