I would prefer 4 (not sure why locations need a name or id … is there really that much intended re-use?), but can live with 3. -jason On Aug 16, 2012, at 8:44 AM, Aaron Brown <aaron@internet2.edu> wrote:
My preference is for all "objects" we define to have id and name options. The effect is pretty much #3, though for XML we'd just force the objects (network, location, etc) to inherit from a BaseObject type that had 'id' and 'name' attributes.
Cheers, Aaron
On Aug 16, 2012, at 8:01 AM, Freek Dijkstra wrote:
I'll take https://forge.ogf.org/sf/go/artf6573 to the list.
In recent examples, it is common to add an "id" attribute and "name" to a Location object.
These attributes are not formally defined: the "name" and "id" are defined in the schema as attributes of a Network Object, but Location is not (a subclass of) a Network Object.
There are a few solutions:
1. Artifact artf6573 proposed to solve this by making Location a subclass of Network Object, but this proposal was opposed by a few group members.
2. Define "id" and "name" in two places in the schema: both as attributes of Network Object, and attributes of Location.
3. Allow "id" and "name" as attribute and subelement for any XML element and as predicates of any RDF Resource.
4. (non-solution) Don't allow "id" and "name" for Locations.
I have a preference for #3. I'm sure this can be done in RDF. Can someone confirm this is possible in XML (RNC/XSD)? Also would this be allowed in a UML schema? (and if this can't be done in UML, do we care? -- I personally don't because I see no implementation issue.)
Freek