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