OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ubl-ndrsc] [Fwd: Global attributes]

Burcham, Bill wrote:
>     I think we may have a problem in saying that we'll name global
>     attributes like local attributes, since we say we'll name local
>     attributes as if they were elements, and (except for top-level elements)
>     these are named as properties of an object class.  Just like top-level
>     elements, global elements nominally don't have an object class. 
> [Burcham, Bill]  Do we need to separate the discussion into a) the 
> attribute name and b) the dictionary entry name for the attribute?  I 
> believe Eve is talking about (b) here.  So, my take is that if we choose 
> to make attributes global then their /dictionary entry names/ might 
> simply be:
>     /attributeName/ 

(Just to clarify, I don't think we want to (or even can) make all 
attributes global; that wouldn't make sense.)

In the case where global attributes are warranted (do we have some draft 
recommendations in Gunther's paper about when they're warranted?), what 
I meant is that our rule for naming leaf elements (and normal 
attributes) relies on an understanding of them as properties of a larger 
object.  Global attributes *can* be seen as properties of a larger 
object, but they're really more like properties of *all* objects.

Oh wait, I think I just talked myself into seeing what Bill's getting 
at.  If you have a ubl:uid attribute on Order and also on Buyer, then 
the attribute can be named "uid" with no problems because it's a 
legitimate property of either Order or Buyer, and the dictionary entry 
for the attribute inside Order will be Order.uid and the entry for the 
other one will be Buyer.uid.  So it's exactly the same case as for 
regular properties (whether they're local attributes or local elements 
or whatever).

That is, the Property Term naming rule for all these things -- local 
elements, local attributes, and global attributes -- can be basically 
the same.

> [Burcham, Bill] (as opposed to /ObjectClass.attributeName/) Making the 
> dictionary entries for attributes global means they can "clash" with our 
> type names (object classes). That is, from the perspective of the data 
> dictionary, attribute names and (complex) type names will be represented 
> in the same (global) namespace.
> As for the attribute name itself (issue a) I don't think we have any 
> such issue of name clashes because I believe that global attributes are 
> in a separate namespace-thingy from global types, i.e. you can have a 
> global attribute and a global type of the same name without ambiguity. 
> (I used the term namespace-thingy because the XSD spec calls it 
> something other than 'namespace' for obvious reasons).

You're right that there's no possibility of name clashes between 
attributes and types.  But anyway, we use the Type suffix to distinguish 

So the net is, I think I withdraw my concern.  But what's left is:

- Ensuring that we have a good rule for when to use global attributes 
(both external and internal)

- Providing global-attribute examples in the naming rules

Eve Maler                                    +1 781 442 3190
Sun Microsystems XML Technology Center   eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC