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
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 _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Internet2 Fall Member Meeting Sep 30-Oct 4, 2012 - Philadelphia, PA http://events.internet2.edu/2012/fall-mm/
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
I'm for solution 3 as well. On 16 Aug 2012, at 14:45, Jason Zurawski <zurawski@internet2.edu> wrote:
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.
Yes there is much re-use, or at least other information that you want to attach to a Location object. And to do that, you need an id. Just for saying that a number of devices are in the same location it is easier to use an ID. To take a practical example, there are many different projects and owners who have hardware at StarLight. It makes things a lot easier if everyone can use an ID to refer to that location. Jeroen.
carrier hotels are multi-story affairs, is the case that all things are located on the same floor, room, cage, 'altitude' :) ? I would expect general location items (lat/long/city, etc.) to stay the same, but extensions to provide more detailed information could force people to use a different location element entirely so they can be precise. In the end i don't really care, it can have id/name, but I don't predict reuse on a grand scale. -jason On Aug 16, 2012, at 8:59 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
I'm for solution 3 as well.
On 16 Aug 2012, at 14:45, Jason Zurawski <zurawski@internet2.edu> wrote:
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.
Yes there is much re-use, or at least other information that you want to attach to a Location object. And to do that, you need an id.
Just for saying that a number of devices are in the same location it is easier to use an ID.
To take a practical example, there are many different projects and owners who have hardware at StarLight. It makes things a lot easier if everyone can use an ID to refer to that location.
Jeroen.
On 16-08-2012 15:03, Jason Zurawski wrote:
... [Location] can have id/name, but I don't predict reuse on a grand scale.
I suspect that in practice all PoPs get one Location object, and since it is common to have multiple devices at a PoP, the same Location id is slapped to all these device. There is the use case of Location id/idRef. I don't think that the same Location objects will be shared between network operators for different networks. And I don't think altitude will be used, except to make fun of our standard ;). IMHO all attributes are optional. Freek
participants (4)
-
Aaron Brown -
Freek Dijkstra -
Jason Zurawski -
Jeroen van der Ham