Question about Entity and its relationship with Extension
In the GLUE Specification v. 2.0, page 8, it is specified the Entity class. In its "Association.End" there is just one field: "Extension.Key", but in the Extension class, its unique identifier is "LocalId". So in the Entity class, it should be specified "Extension.LocalId" instead of "Extension.Key". "Extension.Key" shouldn´t be used because of its description, which I quote here: "This identifier is not required to be unique; several instances of this class MAY hold the same value of this attribute". So this could be another erratum, isn´t it? Regards, David -- David Horat Software Engineer specialized in Grid and Web technologies IT Department – Grid Deployment Group CERN – European Organization for Nuclear Research » Where the web was born Phone +41 22 76 77996 http://davidhorat.com/ http://cern.ch/horat http://www.linkedin.com/in/davidhorat
Hi David, Congrat! You've found a bug :) On Friday 27 March 2009 09:32:05 David Horat wrote:
In the GLUE Specification v. 2.0, page 8, it is specified the Entity class. In its "Association.End" there is just one field: "Extension.Key", but in the Extension class, its unique identifier is "LocalId". So in the Entity class, it should be specified "Extension.LocalId" instead of "Extension.Key".
Correct. At (more or less) the eventh hour, the Extension class was altered to allow multiple Extension objects, each with the same Key (but presumably with different Value attributes). This was done by adding a LocalID and repurposing Key (previously it had the same role as LocalID). I guess the necessary change to Entity's Association End was mistakenly omitted.
So this could be another erratum, isn´t it?
I believe so, yes. Cheers, Paul.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said: At (more or less) the eventh hour, the Extension class was altered to allow multiple Extension objects, each with the same Key (but presumably with different Value attributes). This was done by adding a LocalID and repurposing Key (previously it had the same role as LocalID).
Not exactly: it was always intended that you could have multiple Extensions with the same Key, and the object definition said that explicitly. In xml you could (I assume) do that just by having multiple copies of the object, but in LDAP and SQL you would have to invent an ID to act as a unique key, so we decided to add that explicitly at the schema level rather than leaving it to the implementation. But the upshot is indeed that the relation should use the LocalID. Also, I think this is the one case where we definitely shouldn't allow any freedom about the DIT structure, any Extensions should always be directly under their parent object in the tree since they're logically part of it. Stephen -- Scanned by iCritical.
participants (3)
-
Burke, S (Stephen) -
David Horat -
Paul Millar