|
Oracle® Application Server Syndication Services Developer’s and Administrator’s Guide
10g (9.0.4) Part No. B10667-01 |
|
|
Oracle® Application Server Syndication Services Developer’s and Administrator’s Guide
10g (9.0.4) Part No. B10667-01 |
|
This chapter describes client application development.
Syndication Services provides a Java client library, which can be used to integrate Syndication Services in Java-based Java 2 Platform, Standard Edition (J2SE), or Java 2 Platform, Enterprise Edition (J2EE) applications. The Syndication Services client library lets users request the catalog of offers granted to them, subscribe to one or more of these offers, and receive the associated content. The following sections will describe the code sequence of a sample Syndication Services client application performing the following:
A set of demonstration files, including the full source file of this example, can be downloaded from the Oracle Technology Network (OTN) Web site http://otn.oracle.com/tech/java/oc4j/demos/
A complete listing of the SampleSyndicationClient.java program, parts of which are described in this chapter, can be found in Section C.1. The API documentation that describes how to use the Syndication Services client API can be found on the Oracle Application Server 10g Documentation Library as Oracle Application Server Syndication Services API Reference (Javadoc) under Oracle Application Server Portal. The client library, syndclient.jar, is located in $ORACLE_HOME/syndication/lib on UNIX and in <ORACLE_HOME>\syndication\lib on Windows.
The Syndication Services client library is modeled after the Information Content Exchange (ICE) 1.1 standard. The library is indeed acting as an ICE client in its information exchanges with Syndication Services, which is an ICE 1.1-compliant server. The ICE standard is a content syndication standard defining data structures and information exchanges for establishing syndication relationships. While implementing a generic and interoperable ICE client, the following documentation on the Syndication Services client library will focus on the subset of operations, data structures, and attributes that are relevant to its usage when accessing the Syndication Services server. More detailed information on how Syndication Services maps to ICE can be found in Section 2.9.1.1, Section 2.9.1.2, and Section 2.9.1.3. The ICE specification 1.1 can be found at the following URL http://www.icestandard.org/
When building applications, which interact with Syndication Services, client code should first acquire a SyndicateConnection instance. Example 3-1 illustrates how SyndicateConnection instance can be acquired.
Example 3-1 Acquiring a SyndicateConnection Instance
// Acquire a SyndicateConnectionFactory,
// optionally set the connection parameters,
// such as proxy info, timeout, and credentials.
SyndicateConnectionFactory scf = SyndicateConnectionFactory.getInstance();
// scf.setTimeout(1000);
// scf.setProxy("myproxyhost", iMyProxtPort);
// Create a default XML state handler storing subscription state in a file.
SyndicateClientStateHandler scsh =
scf.getDefaultSyndicateClientStateHandler("synd-client.xml");
SyndicateConnection sc =
scf.createSyndicateConnection("http://myias/syndserver/server", // server url
"myusername", // username
"mypassword", // password scsh);
A SyndicateConnection instance is acquired through the SyndicateConnectionFactory object. The latter contains APIs to set connection properties before their creations. Such properties include: timeout, credentials to be used in case of an HTTPS connection, and the HTTP proxy to be used. Opening a SyndicateConnection instance implies establishing an HTTP connection with Syndication Services, and authenticating as a valid user. In a default Oracle Application Server installation, the Syndication Services server is deployed in the OC4J_Portal instance and the relative path of its URL is /syndserver/server (for example, http://myias:7777/syndserver/server). In order to successfully establish a connection to Syndication Services, the supplied user name and password needs to match the credentials of a valid Syndication Services user. See Section 2.3 for more information about the management of Syndication Services users.
Syndication Services clients are generally stateful. In fact, they need to keep track of the set of subscriptions they created and, when receiving incremental content updates, the state of each of these subscriptions. An instance of SyndicateClientStateHandler can be optionally supplied when nesting a SyndicateConnection instance: SyndicateClientStateHandler exposes a set of interfaces called by the SyndicateConnection instance whenever a client state modification is required, such as subscription creation and updates. The default SyndicateClientStateHandler instance will store subscription state information into an XML file. Custom implementations of the SyndicateClientStateHandler interface, which will, for example, store the subscriptions state in a database, can also be supplied.
SyndicateConnection objects are not synchronized; programmers, who make calls are therefore expected to synchronize their access or create a pool of those connections if building a multithreaded application.
Catalogs are a set of offers available for subscriptions. The catalog structure is illustrated in Figure 3-1 as a Unified Modeling Language (UML) diagram.
Figure 3-1 Structure of a Catalog and Its Main Properties
A catalog is a set of offers optionally grouped in offer groups. An offer represents a content unit, for example a directory in a repository, to which users can subscribe in order to receive content updates. Offers provide accessors for content usage properties, usage licenses, if any, and finally the modes and times in which the offer content will be delivered if a subscription is established. Example 3-2 shows how to acquire a catalog and browse through its offers. In this example, the catalog is grouped by content provider.
Example 3-2 Acquiring a Catalog and Browsing Through Its Offers
Catalog cat = sc.getCatalog();
Offer off = getFirstOffer(cat);
}
private Offer getFirstOffer(Catalog cat)
throws SyndicateException
{
// Iterates through the catalog and returns the
// first offer encountered.
Offer off = null;
Iterator it = cat.getCatalogItems();
while (it.hasNext() && (off == null)) {
CatalogItem item = (CatalogItem)it.next();
if (item.getCatalogItemType() == CatalogItem.OFFER) {
off = (Offer) item;
}
else {
// You got an offer group.
off = getFirstOffer((OfferGroup) item);
}
}
// Print a few offer details.
System.out.println("offer: "+off.getID()+" - "+off.getDescription());
DeliveryPolicy dp = off.getDeliveryPolicy();
if (dp.getStartDate() != null) {
System.out.println("\t start date: "+dp.getStartDate());
}
if (dp.getStopDate() != null) {
System.out.println("\t stop date: "+dp.getStopDate());
}
Iterator dlrs = dp.getDeliveryRules();
while (dlrs.hasNext()) {
DeliveryRule dlr = (DeliveryRule) dlrs.next();
System.out.println("\t dlr mode: "+dlr.getMode());
}
return off;
}
private Offer getFirstOffer(OfferGroup offgrp)
throws SyndicateException
{
Offer off = null;
Iterator it = offgrp.getCatalogItems();
while (it.hasNext() && (off == null)) {
CatalogItem item = (CatalogItem)it.next();
if (item.getCatalogItemType() == CatalogItem.OFFER) {
off = (Offer) item;
}
else {
// You got an offer group.
off = getFirstOffer((OfferGroup) item);
}
}
return off;
}
Example 3-3 shows how users can subscribe to an offer. Subscribing to an offer is achieved by customizing the supplied offer according to the user needs and calling the SyndicateConnection.subscribe method. A typical customization would include setting the destination address and the content format for pushed content packages. For more information regarding the offer customization allowed to users at subscription time, see Section 2.9.3.
Example 3-3 Subscribing to an Offer
// If the offer contains a push delivery rule,
// you can use the offer APIs to set the destination URL.
DeliveryPolicy dp = off.getDeliveryPolicy();
Iterator itdlrs = dp.getDeliveryRules();
while (itdlrs.hasNext()) {
DeliveryRule dlr = (DeliveryRule) itdlrs.next();
if (DeliveryRule.DELIVERY_RULE_MODE_PUSH.equals(dlr.getMode())) {
dlr.setURL("http://mysyndicationclient.com/syndclient/listener");
// Optionally set user name/password.
// dlr.setPushAuthUsername("me");
// dlr.setPushAuthUsername("pwd");
// If raw content is requested (for example, a mailto or
// ftp url has been supplied), set the raw content flag.
// dlr.setRawFormatSupport(true);
}
}
Subscription sbt = sc.subscribe(off);
System.out.println("subscription: "+sbt.getSubscriptionID());
Once a subscription to an offer is established, content can be delivered according to the time periods defined in the offer delivery rules. If the subscription contains push delivery rules, Syndication Services will schedule automatic push updates according to the delivery rule frequency. Refer to the API documentation, which can be found on the Oracle Application Server 10g Documentation Library as Oracle Application Server Syndication Services API Reference (Javadoc) under Oracle Application Server Portal, to see how to configure the supplied SyndicateClientServlet servlet to build an HTTP-based listener, which, upon receiving a push content package, will extract the received content and store it in the local file system. Using the supplied Java APIs, users can use the SyndicateClientServlet servlet to perform custom handling of the received content.
If the subscription contains pull delivery rules, users can request a content update as shown in Example 3-4.
Example 3-4 Requesting a Content Update
// Use a FileSAXPackageHandler instance so that
// syndicate content will be stored in
// the local file system /tmp directory.
FileSAXPackageHandler fsph = FileSAXPackageHandler.getInstance("/tmp/");
// This will get content incremented since the last update.
// The current subscriber state will be fetched from
// the SyndicateClientStateHandler object used by this connection. // To request a full update of the content versus an incremental
// one, use the following syntax:
// sc.getPackage(sbt.getSubscriptionID(),
// SyndicateSubscription.STATE_ICE_INITIAL,
// null,
// fsph);
SyndicatePackage pkg = sc.getPackage(sbt.getSubscriptionID(), null, fsph);
The preceding code sample uses the supplied FileSAXPackageHandler instance to have the received content stored in a file system directory. A custom package handler can be developed using the Syndication Services client library by implementing the SAXPackageHandler interface. Refer to the API documentation, which can be found on the Oracle Application Server 10g Documentation Library as Oracle Application Server Syndication Services API Reference (Javadoc) under Oracle Application Server Portal, for more information.
The returned SyndicatePackage object can be used to iterate through the set of items received in this content update. Figure 3-2 shows a UML diagram of the structure of a content package and its main properties.
Figure 3-2 Structure of a Content Package and Its Main Properties
Syndication Services can request its users to confirm the correct delivery of a content package before the next one can be sent. As the server will send only the content updates since the last request, no new updates will be sent before the server receives a confirmation that everything sent so far has been correctly received and processed.
For push delivery rules whose listener implementation is based on the supplied SyndicateClientServlet servlet, the servlet code will automatically confirm a pushed content package if the content package has been correctly processed by the specified SAX Package Handler interface. Also, if the push URL is SMTP- or FTP-based, if no transport level error is detected during the content transfer, the user state is automatically updated and an implicit confirmation is assumed.
For pull delivery rules, if the received content package requires a confirmation, Syndication Services requires a confirmation to be received before additional deliveries (pull or push) can be performed. Example 3-5 shows how to verify if a confirmation is required and, if so, how to send such a confirmation.
Example 3-5 Verifying If a Confirmation Is Required and Sending a Confirmation
// Check if the content package requires confirmation.
// If so, confirm it.
if (pkg.hasConfirmation()) {
Response resp = _sc.confirm(pkg.getID());
System.out.println("confirmed "+pkg.getID()+":
"+resp.getCode().getPhrase());
}
Example 3-6 shows how the status of a subscription can be verified. The returned information can be used to determine the subscription settings and expiration criteria.
Example 3-6 Verifying the Status of a Subscription
Status sts = sc.getStatus(sbt.getSubscriptionID());
Subscription sbtNew = (Subscription) sts.getSubscriptions().next();
System.out.println(" sbt "+sbtNew.getSubscriptionID()+":");
int pri = sbtNew.getExpirationPriority();
System.out.println(" expiration priority: "+
Subscription.EXPIRATION_PRIORITIES[pri]);
System.out.println(" expiration date: "+sbtNew.getExpirationDate());
System.out.println(" quantity
remaining:"+sbtNew.getQuantityRemaining());
Users can decide to terminate a subscription before it expires. Example 3-7 illustrates how subscriptions can be terminated.
Example 3-7 Terminating a Subscription
Cancellation canc = sc.cancelSubscription(sbt.getSubscriptionID(),
"boring", "en_us");
System.out.println("cancelled: "+canc.getCancellationID());
Users can request Syndication Services for a log of the activity associated with a given subscription. Optionally, a time frame can be supplied to limit the set of events returned. Example 3-8 illustrates how the activity of a subscription can be retrieved.
Example 3-8 Retrieving the Activity of a Subscription
Events evt = sc.getEvents(null, null, sbt.getSubscriptionID());
EventLog evtlog = evt.getEventLog();
Iterator itEvts = evtlog.getEventItems();
while (itEvts.hasNext()) {
EventItem ei = (EventItem) itEvts.next();
if (ei.getType() == EventItem.EVENT_TYPE_MSG) {
EventMsg evtmsg = (EventMsg) ei;
System.out.println(evtmsg.getRequestStart()+" "
+evtmsg.getRequest()+" "+
evtmsg.getResponseType());
}
}
}
}
Section 3.8.1 through Section 3.8.5 describe interface attributes relevant to the Syndication Services server. For more information about these interfaces, see the Oracle Application Server Syndication Services API Reference (Javadoc) that describes how to use the Syndication Services client API; this API documentation can be found on the Oracle Application Server 10g Documentation Library.
This section describes the following offer attributes relevant to the Syndication Services server:
ID -- the ID of the offer. It uniquely identifies an offer.
Description -- a textual description of the offer and the content associated with it. The description helps a user understand if he is interested in subscribing to such an offer.
Product Name -- a name that may be used to distinguish subscriptions and offers from other subscriptions or offers. Its intended use is to provide a readable short description of the offer such as, "Julia Child's Contemporary French Cooking Column".
Atomic Use -- if true, all delivered content in the subscription must be used together, or not used at all. If false, then the user is permitted to use subsets of the data in any way desired (and as permitted by the licensing terms, of course).
Editable -- if true, the user may edit or alter the content before using it. If false, the user is expected to use the content without any alteration.
Intellectual Property Status (IPStatus) -- a string specifying the intellectual property-rights status of the content. ICE 1.1 defines the following specific string values:
PUBLIC-DOMAIN: the content has no licensing restrictions, whatsoever.
FREE-WITH-ACK: the content has no licensing restrictions beyond a requirement to display an acknowledgment of the content source.
SEE-LICENSE: the content has licensing restrictions as already agreed to in an existing licensing agreement. This is meant to convey the default case.
SEVERE-RESTRICTIONS: the content has licensing restrictions that are worthy of special attention.
CONFIDENTIAL: the content is confidential and must be protected specially.
Rights Holder -- a string specifying the original source of the syndication rights.
Show Credit -- if true, the subscriber is explicitly expected to acknowledge the source of the data.
Usage Required -- whether or not the syndicator expects the subscriber to return usage data regarding the ultimate viewers of the syndicated content. Syndication Services does not define the format (or transport) of this usage data; however, this attribute lets a syndicator programmatically indicate the need for the data to the subscriber.
Business terms provide the means for additional content and parameters to be communicated and negotiated between the parties. They generally contain the license agreement that the syndicator wants the user to acknowledge as being acceptable before accepting a subscription and delivering the associated content.
The offer delivery policy describes the duration of a subscription. The delivery policy start date determines when the delivery of content starts. The expiration of the subscription is determined by a combination of attributes: the offer expiration priority attribute defines the criteria that will determine the subscription expiration. A subscription can expire after a certain number of content deliveries has been performed, or it can expired on a given date, or a combination of the preceding criteria. If the expiration priority value is first, then the subscription terminates when the first of the quantity or the delivery policy stop date is reached. If the expiration priority value is last, then the subscription terminates when both the quantity and the delivery policy stop date are reached. If the expiration priority value is time, then the subscription terminates when the delivery policy stop date is reached. If the expiration priority value is quantity, then the subscription terminates when the quantity is reached.
A delivery rule defines a period of time in which deliveries can be performed. Each delivery rule can be either a push (content is automatically delivered by the syndicator to the users) or pull (content delivery is requested by the user), can define which years, months, dates, and days of the week in which deliveries can be performed, a start and end time for the update period, and the count of the number of updates that can be performed.
The idea is to define a daily time period (defined by a start time and a duration) during which the deliveries happen. The start date, week day, month day, and stop day will define the day to which the daily time period will be applied. The most relevant delivery rule attributes are summarized as follows:
mode -- a value of either push or pull. A push delivery means that the update is initiated by the syndicator. A pull delivery means that the update is initiated by the user.
Monthday -- the delivery restricted to the given day of the month. This attribute is in the range 1 to 31, inclusive, or can be the special value any meaning no restrictions, or it can be the special value last meaning the last day of any month. Multiple values may be specified, separated by ' ' (a space).
Weekday -- the delivery restricted to the given day of the week. This attribute must be in the range 1 to 7, inclusive, or be the special value any, meaning no restrictions. Multiple values may be specified, separated by ' ' (a space). In accordance with [ISO860] Section 5.2.3, the days are assigned as follows:
Monday is day number 1.
Tuesday is day number 2.
Wednesday is day number 3.
Thursday is day number 4.
Friday is day number 5.
Saturday is day number 6.
Sunday is day number 7.
Startdate -- the beginning of the delivery rule time period. If earlier than the start date in the containing delivery policy, implementations must act as if this were equal to that start date. If no start date is supplied, the time period begins on the start date specified in the containing delivery policy. If there is no start date in the containing delivery policy, the time period begins immediately.
Stopdate -- the end of the delivery rule time period. If later than the stop date in the containing delivery policy, implementations must act as if this were equal to that stop date. If no stop date is supplied, the delivery will end based on the stop date in the containing delivery policy, or, if the latter is not supplied, delivery never ends.
Starttime -- the beginning time of a time period. If not defined in the subscription duration, a beginning time of 00:00:00 Coordinated Universal Time (UTC) will be applied. If the day under consideration is the first day, the time period begins at whichever is later: start time or the time portion of the start date.
Duration -- the length of a daily time period. Duration will not exceed 24 hours. If the start time and duration are not supplied, the time period is supplied to cover the whole day. If the start time is specified, and duration is not specified, then the semantics are as if a duration had been specified such that the time period will last from the start time until 24:00:00 UTC.
min-num-updates -- the number of updates that the user is expected to receive during the time period identified by the start time and the duration. In Syndication Services, this parameter applies only to the push delivery rule.
url, pushAuthUsername and, pushAuthPassword -- the address to which to send the update, if it is not to be sent to the normal ICE communication end point (see Table 3-1). In Syndication Services, the URL supplied may be either an HTTP or HTTPS protocol where a client listening to push packages is running. Other supported protocols include SMTP (for example, mailto:myemail.com) or FTP (for example, ftp://myserver/mydir). Optionally, if authentication is required, the user name and password of the user to be used can be supplied.
Table 3-1 Push Delivery Options
| Push URL Protocol |
ICE Push (packageFormat=ICE_PACKAGE_FORMAT) |
Non-ICE Push (packageFormat=NON_ICE_PACKAGE_FORMAT or NON_ICE_NO_LOG_PACKAGE_FORMAT) |
|---|---|---|
HTTP (for example, http://user.com/syndclient/client)
|
Syndication Services will perform an HTTP POST to the user HTTP end point containing the ICE XML package according to the ICE 1.1 specification. | Syndication Services will perform an HTTP POST to the user HTTP end point containing a MIME multipart message, where each part is a content package item. If the NON_ICE_PACKAGE_FORMAT option is chosen, an additional part (the log) with a content package summary is also attached. |
FTP (for example, ftp://user.com/usr/homedir)
|
Syndication Services will log in to the specified FTP site. It will change the current directory to usr/homedir/. It will then upload the ICE XML package as a single XML file whose name will be the <package-id>.xml.
|
Syndication Services will log in to the specified FTP site. It will change the current directory to usr/homedir/. It will then upload each content package item as a separate file retaining the item content-filename attribute and creating the necessary subdirectories. If the NON_ICE_PACKAGE_FORMAT option is chosen, an additional file whose name is the <package-id>.log with a content package summary is also uploaded.
|
SMTP (for example, mailto:user@user.com)
|
Syndication Services will send an e-mail message with a single part containing the ICE XML package. | Syndication Services will send an e-mail message with a mail attachment for each content package item. If the NON_ICE_PACKAGE_FORMAT option is chosen, an additional text attachment (the log) with a content package summary is also attached. |
|
Note: oracle.syndicate.transport.ftp.act_connect_mode, an FTP property, controls FTP content pushes that are executed using active or passive FTP connection modes. See Section 2.9.5 for more information about this Syndication Services advanced property.
|
Raw format support -- whether or not content updates are in the form of an XML payload (ICE XML package), a mail attachment (SMTP), or simply uploaded to the specified FTP server when an FTP URL is supplied.
Syndication Services will send content updates to the specified address in the form of an XML payload (ICE XML package). It is up to the receiving client to understand the package structure and extract the content from it. Refer to the API documentation, which can be found on the Oracle Application Server 10g Documentation Library as Oracle Application Server Syndication Services API Reference (Javadoc) under Oracle Application Server Portal, to see how to configure the supplied SyndicateClientServlet servlet to build an HTTP-based listener, which, upon receiving a push content package, will extract the received content and store it in the local file system. Using the supplied Java APIs, users can use the SyndicateClientServlet servlet to perform custom handling of the received content.
Syndication Services also offers the option for receiving the updated content without enclosing it into an ICE XML package. When setting this option, users will receive the updated files in the form of a mail attachment when using SMTP, or the updated content will be uploaded to the specified FTP server when an FTP URL is supplied.
A SyndicatePackage interface describes a set of content operations: removals and additions. The remove operation is specified using the ItemRemove interface. The content additions contain the content that needs to be added or updated and is specified using the Item and ItemRef interfaces. The ItemGroup interface lets the syndicator associate the content specified using the Item and ItemGroup interfaces together. The Item and ItemRef interfaces distinguish themselves by the way they contain the content. The Item interface is used to contain content directly in the delivered content. The ItemRef interface is used to distribute an indirect reference to the actual content. The SyndicatePackage interface specifies an old state and a new state. Before the new state can be reached, all operations contained within a content package should be processed. If an operation cannot be performed successfully, all previously performed operations specified in the content package should be undone, so the user is not left in an inconsistent state. The SyndicatePackage interface exposes a set of accessor methods to manage its attributes. The most relevant attributes of the SyndicatePackage interface are summarized as follows:
activation -- the date and time when the content contained in the content package may be used, as defined by the specific business relationship between the user and syndicator. If this same attribute is used on a specific item or group within the content package, the value specified there overrides this general specification within that part of the content package hierarchy. If this attribute is omitted, the content contained within the package is available for the user to deploy at his discretion.
atomic-use -- a presentation constraint that either all content to be delivered must be used, or none of it is allowed to be used.
confirmation -- whether or not the syndicator requires confirmation that the delivered content package was indeed delivered and processed successfully.
editable -- whether or not the user may modify the information or must use it exactly as it is delivered.
expiration -- the date and time after which the content contained in the package must not be used. If this same attribute is used on a specific item or group within the content package, the value specified there overrides this general specification within that part of the content package hierarchy.
fullupdate -- whether or not the processing of the content package requires a full update of all content previously delivered in the subscription.
new-state -- the state of the subscription after successfully processing the content package. This is an opaque value to the user, or something in which the user does not have direct access. The user can supply this state to the next getPackage request in order to receive the incremental update since then.
old-state -- a string that specifies the state of the subscription before processing this content package.
package-id -- the content package within the scope of a subscription. This is the value that will be used when confirming content packages, if required.
show-credit -- whether or not the subscriber must prominently display attribution for the content source.
subscription-id -- the subscription to which this content package belongs.
Attributes of the Item and ItemRef interfaces explicitly contain the content being distributed. The default content model for an attribute of the Item interface is character data. Binary data can be transmitted within an attribute of the Item interface by using a base64 value. The attributes of the ItemRef interface manage the pointer to the content; its content is included in a content package delivery by reference. To learn how to access and process item content data, refer to the API documentation, which can be found on the Oracle Application Server 10g Documentation Library as Oracle Application Server Syndication Services API Reference (Javadoc) under Oracle Application Server Portal, for information about the SAXPackageHandler interface. The most relevant attributes of the Item and ItemRef interface are summarized as follows:
activation -- the date and time when the content contained in the package may be used. If this same attribute is used on a specific item or group within the content package, the value specified there overrides this general specification within that part of the content package hierarchy.
expiration -- the date and time when use of the content expires. If this same attribute is used on a specific item or group within the content package, the value specified there overrides this general specification within that part of the content package hierarchy.
content-filename -- the relative destination for the item indicated by the syndicator. Paths stated in the content-filename attribute are represented using forward slashes as a path element delimiter. The subscription root is defined as a logical directory within which the user will place all file-based content received from the syndicator for that subscription; if the content-filename attribute begins with a slash, the user must still treat the path as relative to the subscription root directory.
content-transfer-encoding -- the encoding of the data contained in, or referenced by a PackageItem attribute. The only valid values are x-native-xml and base64. These values are derived from RFC-2045, sections 6.2 and 6.3. The x-native-xml value indicates that character entities may have been used to protect the special characters identified in Section 2.4 of the XML 1.0 W3C Recommendation. The base64 value exhibits the same properties as that defined in Section 6.8 of RFC-2045. The base64 value provides a means to distribute binary data, such as graphics formats, and other humanly unreadable data formats. Future versions of ICE may expand on this set of values.
content-type -- the media type of the content, and should adhere to RFC-2045 and RFC-2046, including setting the charset parameter. The default value, application/octet-stream, indicates the opaque nature of the content being distributed.
ip-status -- a string that specifies the intellectual property-rights status of the content.
item-id -- the item uniquely identified within the scope of the containing content package.
rights-holder -- the entity that holds the original syndication rights to the content in this element.
show-credit -- whether or not the element’s content requires crediting the source. This attribute must have a value of true, yes, false, or no. A value of yes or true indicates that use of this element's content requires crediting the source. A value of no or false means that source crediting is optional. The default value is no.
subscription-element -- the content item persistently identified over the duration of the subscription. The only way to explicitly update or remove an individual content item is to use its subscription-element identifier in an operation in a subsequent content package. Alternatively, a full update will be required that will remove all of the content associated with the subscription.
name -- the logical identifier for the content.
|
 Copyright © 2001, 2003 Oracle Corporation All rights reserved |
|