UBL Naming and Design Rules SC

 View Only

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

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

    Posted 01-30-2002 14:24
    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>