/**
* Copyright 2006 OCLC Online Computer Library Center Licensed under the Apache
* License, Version 2.0 (the "License"); you may not use this file except in
* compliance with the License. You may obtain a copy of the License at
* http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or
* agreed to in writing, software distributed under the License is distributed on
* an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
* or implied. See the License for the specific language governing permissions and
* limitations under the License.
*/
package info.openurl.oom.entities;
/**
* This interface is an abstraction for the categories of information
* represented in a web service request. In layman's terms, these
* categories are synonymous with who, what, where, why, when, etc.
*
* @author Jeffrey A. Young
*/
public interface Entity {
/**
* Get a sequence of descriptors for this entity. Use
* the instanceof operator to select desired descriptor
* types from the list.
* <p />
* Analysis: The OpenURL specification defines a set of
* abstractions to represent descriptors: Identifier (URI),
* By Value Metadata, By Reference Metadata, and PrivateData
* (everything else). To be fair, these represent categories
* that are useful for the handful of transports defined by
* the spec in a language independent way. In contrast, OOM-J
* doesn't need to be operationally constrained by language
* independence and shouldn't feel obligated to give special
* status to the quirky descriptors used by legacy Transports.
* <p />
* Normal Transports can completely ignore this whole mess:
* any Java Object is a legitimate descriptor. Unfortunately,
* the XML Schemas used to document OpenURL applications
* reflect this bias, but it is easy enough to dumb our Java
* Object descriptors down when the time comes to register
* the application.
* <p />
* As a consequence, the OOM model does NOT provide a Descriptor
* interface to encapsulate the four types of descriptors
* enumerated in the OpenURL 1.0 spec: Identifier, By
* Value Metadata, By Reference Metadata, and PrivateData.
* As described below, every Java Object qualifies
* as a legitimate descriptor one way or another, so why
* create an abstraction for something that is already abstract?
* <p />
* Identifier is <em>not</em> modeled in OOM because it is
* functionally equivalent to the URI class and there is
* no sense in creating an Identifier abstraction for a single
* class of objects.
* <p />
* Interfaces <em>are</em> provided for By Value Metadata
* and By Reference Metadata because they are generally
* useful and, unlike URI, there is no native Java class
* that represents them unambiguously.
* <p />
* PrivateData is <em>not</em> modeled because it is
* functionally equivalent to Java's Object class and
* there is no good reason to create an abstraction
* for something that is already abstract.
*
* @return an array of Objects that describe this entity
*/
public Object[] getDescriptors();
public void addDescriptor(Object descriptor);
/**
* This utility method allows Service classes to select a
* subset of descriptors that are instances of the specified
* Class.
*
* @param c the Class of descriptors
* @return an array of Objects that describe this entity that
* are instances of the specified Class
* @deprecated Introspection isn't available in some languages, so
* this method will have to be removed before the official release.
*/
public Object[] getDescriptors(Class c);
}