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: Mon, 22 Aug 2005 09:19:53 -0400
Andre,
I think I am probably missing your concern(s).
I understand the XML specs in the following
manner:
- Element names are required to
be QNames. This name provides semantic information concerning the contents,
but is not required to supply syntactic information (i.e. is not required
to resolve to a GED [global element definition]).
- Elements are encouraged to use
the xsi:type attribute to provide a QName reference to a syntactic definition
of the element. This is especially important when there is no GED.
Are
you arguing that since, in the presence of a GED, #1 can be sufficient,
WSRP should only allow for it and thereby require GEDs?
The protocol already provides hooks for carrying descriptions of things
which are outside the protocol. How is this metadata hook any different?
By the way, remember that one of the
reasons we started down this path originally was that the name of an ItemDescription
is, in practice, insufficient for describing a custom user profile item.
Rich
"Andre Kramer"
<andre.kramer@eu.citrix.com>
08/22/05 08:34 AM
|
To
| Rich Thompson/Watson/IBM@IBMUS, "wsrp"
<wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp] ExtensionDescription |
|
Sounds more like “colocation”
is suggested rather then “location”. But that seems a partial and somewhat
arbitrary constraint description. I don’t think we designed our types
with independent extensibility in mind and see no particular reason to
do so.
On what we already have, ModelDescription/ModelTypes
wraps an “any” to communicate actual schema (not sure how useful this
is) and this seems closer to purpose than EventDescription for Events,
which I agree features the double QName. However, event naming and
event typing are two pretty well defined aspects of event representation,
which I do not think carry over. Currently, our ItemDescriptions carry
a single “itemName” which logically (for me) is a QName, serving as a
single naming & type identification, just as XML element names commonly
do. [Looking at ItemDescription, I think that we should make the “itemName”
a sub-element rather than an attribute, as we currently have it, even if
we do not enforce that it should be a QName.]
In the end, it’s the lack
of (portable) examples that causes me concern, leading me to think that
supplying schema information may be a larger issue that we may be able
to address globally in 3.0. Even with a single QName for typing and a more
expressive “location” description, I would still oppose this one on the
grounds that our protocol should not describe things outside itself (extensions)
and that one should not mix documents (extensible exchanges) with their
structural descriptions.
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 22 August 2005 12:23
To: wsrp
Subject: RE: [wsrp] ExtensionDescription
comments inline
Rich
"Andre Kramer"
<andre.kramer@eu.citrix.com>
08/22/05 04:09 AM
|
To
| Rich Thompson/Watson/IBM@IBMUS,
"wsrp" <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp] ExtensionDescription |
|
Leaving aside the more philosophical questions, I don't see why you propose
both a QName name and type and how locations can cover multiple uses of
the same protocol type.:
RT> The QName for the name provides information on what will flow at
runtime. From both protocol and XML points of view, this QName relates
to the semantics of the extension. The QName for the type points at the
definition of the structure that will flow at runtime. From both protocol
and XML points of view, this QName provides the syntax of the extension.
In theory one could eliminate the 'type' QName by requiring the 'name'
QName be a GED within a schema (thereby deferring the type definition to
that GED definition), but this would be inconsistent with what we have
done before (e.g. properties) and neither pattern is a preferred XML pattern.
Is a single QName not enough to both recognize an XML element (wrapped
as an extension) and prime the deserializer? I could image a URL for a
schema (still) being required to actually locate the content model description
but not a second QName. Maybe a fully worked example of how a processor
recognizes an extension (type) and deserializes it is needed to allow us
to access if the proposed description is adequate or useful.
RT> A fully worked example would be very processor dependent. However,
the processors I am aware of separate the syntax issues of deserializing
a message (i.e. use of the 'type' ... handled by the stack) from the semantic
issues (i.e. use of the 'name' ... handled by the app).
What if one of our types (maybe in a future version of the protocol) can
occur at more than one level in the XML hierarchy? How do you encode this
with “locations”? Also, do locations not have to be per protocol message
to clearly define what is acceptable when?
RT> The potential complexity this introduces is why it was suggested
on the call that 'location' simply be a type name. The definition says
that the extension could (but is not required to) appear anywhere that
type appears. The other alternative would be to provide some sort of nesting
syntax to say that when strucA is nested inside strucB within strucC, a
particular extension might be used. My sense from the call was that while
this would be a more definitive means to indicate 'location', people were
not interested in the complexity it introduces. [By the way, various types
can already appear in various messages with differing XML hierarchies;
for example, PortletDescription]
Regards,
Andre
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 19 August 2005 22:11
To: wsrp
Subject: [wsrp] ExtensionDescription
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
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 ---------------------------------------------------------------------
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]