OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]