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: [wsrp] ExtensionDescription



While doing the pass to determine if there where places other than eventing where an optional payload should become mandatory if the related metadata specified a type for the payload, I came across a tangentially related area in ExtensionDescription.

Currently ExtensionDescription (5.1.21) have a required name & type with optional aliases, descriptions and locations.

The issue I noticed is that while each Extension should have a distinct QName for its name, it has the potential to have different payloads depending on the location being extending. For example, suppose I am defining a new extension foo:bar. Unless this is a simple extension (e.g. extends just one structure or a set of structure with the same info), I am likely to end up specifying a number of things:
 - extend ServiceDescription/RegistrationData with metadata defining whether any optional parts of the foo:bar extension are supported.
 - extend one or more request messages with additional information the Consumer will supply to the Producer
 - extend one or more response messages with additional information the Producer will supply the Consumer

Do others agree this would be the pattern for more involved extensions?
If so, would people agree to moving type and locations[] into a new structure which ExtensionDescription then includes as an array?

Rich


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