MHonArc v2.5.2 -->
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
types...
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
--
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