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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: RE: [dss] Finalizing core spec


At 03:19 PM 4/14/2004 -0400, Paul Madsen wrote:
>Hi Trevor
>
>1) core 18 refers to both 'ServiceProfile' (line 463) and 'Profile'
>attributes

It'll be changed to 'Profile'.


>2) Wrt to keeping the Profile attribute and using an <AdditionalProfile>
>element for any profile designators beyond that, I would prefer a
>symmetrical mechanism. Using an attribute for one profile and an element (in
>another location) for others might suggest an unintended semantic to DSS
>Servers, i.e. 'the value in the Profile attribute is the real profile and I
>can probably ignore the others'.

What I like about having a "main profile" is that it can guide the 
interpretation of the "additional profiles".

For example, the main profile can say:
  - no additional profiles are allowed
  - these 3 addititional profiles are allowed: X, Y, Z, and when they're 
active, this is how the combined profile should be interpreted

Otherwise, if they're all symmetric, there's no ultimate authority to say 
what the combined profile means.  Well, maybe that's the idea.

I think it's still an open issue how exactly all this should work:
  - Is there a main profile, or are they all equal?
  - Should these be "optional inputs", or mandatory parts of the core protocol?


>Separate but perhaps related, as far as I know, we discount the potential
>for the DSS Server being able to indicate profile(s) on its Response. Is the
>client simply expected to remember under what profile(s) the request was
>sent and correlate the response approriately? Perhaps this is only relevant
>for asynchronous interactions?

I guess we've been assuming the client can remember it.  Another argument 
for putting the 'Profile' in the response is that the client may not have 
indicated a profile at all, or the server may have used a particular 
sub-profile of the indicated profile.

It would be easy to add a 'Profile' attribute to the response, and probably 
a good idea.  Of course, if we do multiple-profiling, like above, that'll 
affect this.

Trevor




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