I understand the proposal, on which we
have philosophical differences concerning the nature of extensionality, such as
whether or not a textual description field is adequate. For the call today
(assuming I’ve caught up with the call scheduling) I would ask two
questions:
Why would we want to describe in band what
we have now said is content that is can be processed by “lax”
rules? (See schema for extensions with processContents=“lax” attribute).
Why would we add such extension metadata
to the protocol when a simple extension can be used to transfer just such data?
i.e. One can send the proposed “metadata” triple in an <extensions>
element.
Regards,
Andre
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: 31 August 2005 13:29
To: wsrp
Subject: Re: [wsrp]
ExtensionDescription
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
--------------------------------------------------------------------- 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