Re: [ubl-ndrsc] Elements vs. attributes: discussion kickoff

[Doug Bunting <dougb62@yahoo.com>]

Eve,

If I remember the details of the XSD specification, default values for
elements don't work the same (relatively intuitive) way as those for
attributes.  In particular, a missing optional element with a default value
isn't added to the post schema validation infoset.  I don't remember the
details but it might mean an element with a default value has to be present in
an instance (but empty?) to make the default "work".

Gunther,

In general, your document looks good but seems to expect only DTD-aware
processing, especially around datatype support.  Your comments about attribute
ordering are also slightly incomplete since order is significant for values in
a list such as NMTOKENS.  I completely agree with all space efficiency and
clear semantic differentiation arguments in favour of attributes.

Could you correct a few typos while revising the document?  I tripped over
"The type of attribute that relating...", "Attributes can be built in are
unordered" and "Attributes are ambiguity and not..."

Very much related to this discussion but coming out of the face-to-face
minutes, the choice of ID for all Identifier representation terms seems
problematic given a tendency for XML parsers to assume all attributes named
"ID" have type "ID" and preventing duplication within a document.  I've seen
problems with this first hand because documents are often combined to create
larger ones.  Unscoped uniqueness constraints fit well only for documents that
will never be combined and we can't mandate in this area.  My apologies if I'm
misunderstanding the minutes or otherwise trodding through material already
covered.

thanx,
    doug

"Eve L. Maler" wrote:

> One of the more critical areas we need to decide is "elements vs.
> attributes".  Gunther's position paper is here (he's going to update it soon):
>
> http://www.oasis-open.org/committees/ubl/ndrsc/pos/draft-stuhec-elemvsattrib-01.doc
>
> Here are a few unorganized thoughts to get the discussion going; everyone,
> please respond with your thoughts, and I'll try to formulate votable
> questions as we go:
>
> I think the analysis in this paper about advantages and disadvantages of
> attributes is mostly on target (I have a few quibbles that I'll try to
> write up soon).  I'd like to see the advantages and disadvantages of
> elements described fully in similar fashion.
>
> 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.
>
> 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?).
>
>         Eve
> --
> Eve Maler                                    +1 781 442 3190
> Sun Microsystems XML Technology Center   eve.maler @ sun.com
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>