[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Make targetID an attribute.
I'd like to make "targetID" an attribute (rather than an element). - TargetID always occurs as an instance of IdentifierType which (extends ExtensibleType but) really comes down to just a string "ID" attribute. - Modeling targetID as an attribute would be simpler and clearer and much easier to explain in the spec ;-). The problem with the current definition of IdentifierType is that it is not clear whether the unique identifier for each target occurs as the *content* of the <targetID> element or occurs as the value of that <targetID> element's "ID" *attribute*. (We originally wanted PSOIdentifierType to extend IdentifierType because we thought this would allow a PSOIdentifierType to flow through the protocol as an instance of IdentifierType. However, we subsequently discovered that XML has no magic polymorphism--as in the case of nested requests.) Right now, targetID occurs in four contexts: - TargetType#targetID - PSOIdentifierType#targetID - AddRequestType#targetID - SearchRequestType#baseTargetId Jeff Bohren is also planning to add "targetID" to SchemaEntityRefType in an upcoming revision of the XSD. (We need this so that a ReferenceDefinition element can refer to a schema entity that is supported by another target.) If we say that "targetID" is a string attribute, then: - TargetType#targetID becomes a required string attribute (rather than a required sub-element). - PSOIdentifierType could still extend ExtensibleType, but adds two required attributes: "targetID" and "objectID" (both of type string). - AddRequestType (rather than offering a choice between a "targetID" element and a "containerID" element) would simply require a "targetID" attribute and allow an optional "containerID" attribute (again, both of type string). - SearchQueryType (rather than offering a choice between a "baseTargetID" element and a "basePSOId" element) would simply require a "baseTargetID" attribute and allow an optional "basePSOId" attribute (again, both of type string). - SchemaEntityRefType#targetID would be an optional string attribute (rather than an optional sub-element). I think this would be a lot simpler and just as functional. (It's certainly easier to document.) I've discussed this idea with Jeff Bohren, and he agrees that targetID could be an attribute. Does anyone object?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]