[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsrp] ExtensionDescription
ExtensionDescription Type
An extension MAY be described using the following structure. This provides an optional means for the Producer and Consumer to exchange metadata concerning items which could appear within an extensions element of WSRP-defined messages:
ExtensionDescription
[R]
QName name
[R]
QName type
[R]
LocalizedString
description
[O]
string
locations[]
[O]
Extension
extensions[]
Members:
name: Name of the extension being described, MUST have a non-zero length. This name will appear in any runtime instance of the extension as the fully qualified XML element name.
type: The type of the extension element, using a namespace qualified name. The purpose for this information is to enable the receiving party to prepare an appropriate deserializer.
description: A localized, human-readable description of the extension. This description should include the semantics of the extension.
locations: An array of type names from the WSRP protocol where this extension can be expected. If no locations are supplied, the extension could appear on any WSRP defined type.
extensions: The extensions field MAY be used to extend this structure. Extension elements MUST be from namespaces other than WSRP.
2. Fields of type ExtensionDescription:
- replace ServiceDescription.customUserProfileItemDescriptions[]
with extensionDescriptions[]. Note
the broadening of this field in its description.
- add [O]
registrationData.extensionDescriptions[] with
the field description noting that the Consumer is supplying metadata about
extension it supplies on runtime messages.
3. Discussion:
There were questions raised about whether
this philosophically broke with either the XML concept of what it means
to say the type of an element is <any/> and/or the nature of extensions
being outside the protocol. I don't see either of these as an issue since
what would be transferred is metadata about elements from outside the protocol
that might appear in a runtime message. I could possibly see such metadata
being an issue if we required the described extension to always appear
(one might argue using XML Schema to extend the data structure would be
more appropriate), but the intent is to provide syntax (replicated in the
runtime message, but provided at discovery time to enable preparation to
handle the actual content, much as is done for properties) and semantics
of what might appear within the open content of the extensions element.
I don't think this violates even the spirit of the XML specs.
As to the question about extensions
being outside the spec; we have several areas where extensibility is enabled
(properties, modes, windowStates, etc) and the protocol supports carrying
metadata about actual extensions so that the other party can discover and
potentially prepare to handle receiving the extension. I think this is
just another example of enabling a metadata exchange about items that go
beyond what the WSRP spec defines.
Rich
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]