wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] ExtensionDescription
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp <wsrp@lists.oasis-open.org>
- Date: Wed, 31 Aug 2005 08:29:19 -0400
I'm sorry if it hasn't been well communicated,
but the key idea of this proposal is to provide an in-band method for carrying
user-defined metadata about an extension. The base for this metadata provides
for identity (i.e. the "name" field), syntactic (i.e. the "type"
field) and semantic (i.e. the localized "description" field)
elements. None of these are more or less important than the others. Also,
the proposal defines nothing about any particular extension.
Rich
Subbu Allamaraju <subbu@bea.com>
08/30/05 08:43 PM
|
To
| wsrp <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [wsrp] ExtensionDescription |
|
I would lie to comment that, the key idea of this
proposal is to
formally describe data types for extensions in the WSRP schema.
Strictly speaking, a protocol extension needs two things to work - (a)
description of data types (in an xsd), and (b) description of semantics
(in a spec). Both are required to make a protocol extension work. I
don't think it is the place for the spec to describe neither the types
the semantics for protocol extensions, since the moment an extension is
described formally in the spec, it is no longer an extension. Given
this, I don't see value in adding data types for extensions in the WSRP
schema.
Secondly, an Andre pointed out today in the interfaces thread on his
proposal, implementations are not required to understand extensions. By
formally describing that something be carried as an extension, we are
creating a need to understand extensions even when an implementation is
not extending the protocol. Custom user profile items are spec-defined
entities requiring an open content model for transport, and we can't
piggyback on extensions at the transport level.
Regards,
Subbu
Rich Thompson wrote:
>
> As part of considering more fully describing those custom user profile
> items which augment the spec-defined user profile structures, I was
> asked to develop a broader proposal that enables describing extensions
> more generally.
>
> */The proposal:/*
> *_1. Add a type for describing an extension:_*
>
> *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 <\l_LocalizedString_Type>
description
> [O] string
<\l_LocalizedString_Type_1> locations[]
> [O] Extension <\l_RegistrationContext>
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
> ---------------------------------------------------------------------
To
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs
in
> OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs
in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]