OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[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]