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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf-editors message

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


Subject: Re: [ws-caf-editors] Re: Latest revisions



> Mark, et al, thanks for the reply. I wanted to comment on a few of your
> comments (and try to get a group consensus).
>
> comment1: you want the deleted text to be restored. I removed it because
> it is word-for-word redundant to the abstract. I will try to cut and
> paste the statement on scoping work up toward the activity description,
> which will mean that only one sentence is repeated. I'd like to
> carefully review the abstract when we have things done.
>
> comment3: I don't know that we need them; I didn't change the structure
> except to add the deref element. What's the consensus?

Peter has raised an issue so we should probably discuss this on the list.

>
> comment4: I will double check with Simeon today about the positioning of
> the any element.
>
> comment5: the rationalizations for nesting were not to resolve an issue,
> they were to address concerns raised by Peter and Alastair about nesting
> in general -- and were included in the model description exercise. We
> agreed in New Orleans to remove this text from the spec, but to add it
> to either the FAQ or the primer.

OK, my memory needs augmentation ;-)

Mark.

>
> Greg
>
> > Mark Little wrote:
> >
> >> Comments inline.
> >>
> >> Mark.
> >>
> >> ----- Original Message -----
> >> From: "Greg Pavlik" <greg.pavlik@oracle.com>
> >> To: "Greg Pavlik" <greg.pavlik@oracle.com>
> >> Cc: "ws-caf-editors" <ws-caf-editors@lists.oasis-open.org>
> >> Sent: Thursday, May 20, 2004 9:00 PM
> >> Subject: [ws-caf-editors] Re: Latest revisions
> >>
> >>
> >>
> >>
> >>> Attached.
> >>>
> >>> Greg Pavlik wrote:
> >>>
> >>>
> >>>
> >>>> Gentlemen,
> >>>>
> >>>> I have gone through to resolve my open issues and also to attempt to
> >>>> tidy up the spec by flagging redundancy and content we agreed to
> >>>> remove at the F2F (for example, the rationalizations for nesting
> >>>> belong in an FAQ or the Primer).
> >>>>
> >>>> Please read this revision and check to make sure you agree with the
> >>>> changes I have made. I have modified the context structure and added
> >>>> text on both addressing/service references and on getting the value
of
> >>>> a context that is passed by reference. Make sure that you agree with
> >>>> what is in there.
> >>>>
> >>>> However, I have some action items for you all:
> >>>>
> >>>> 1) Eric, Mark: please make you agree with the defintion(s) of
> >>>> activities. Make sure that all explanations of activities are
> >>>> consistent with reference to the execution environment and contexts.
> >>>> 2) Eric, Mark: Please look for redundancy: it's annoying and it makes
> >>>> the spec ultimately harder to read and maintain. I tried to eliminate
> >>>> things that I thought were repetitive and unhelpful, let's talk
before
> >>>> we undo the deletes.
> >>>> 3) Simeon: I have made several changes to the schemas and XML
> >>>> instances -- the changes aren't hard to find -- they need a) to be
> >>>> backported to the real schema/wsdl that you maintain and b)
validated.
> >>>> Note that the SOAP example is currently incorrect, as the proper
> >>>> namespaces are not imported. Also, let's revist whether we actually
> >>>> need the "generic" service-ref element. I'm starting to think not.
> >>>> 4) Speaking of namespaces, we no longer have a section that says what
> >>>> namespace prefixes refer to. Is this an oversight? Let's give this
one
> >>>> to Mark.
> >>>> 5) Mark, can you just remove the getContents method from
> >>>> ContextService?
> >>>> 6) What exactly is returned when a URL in a pass-by-reference context
> >>>> is dereferenced? An XML document that contains the context structure
> >>>> as understood by the issuing authority? We should spell this out; if
I
> >>>> recall, the ContextManager responds with a requested-context message.
> >>>> 7) Does anyone have an action to map the request-reply messages into
a
> >>>> (normative) table as per Peter's F2F request? This is actually
> >>>> important as it allows us to avoid by normative rules requirements in
> >>>> the callback pattern when using WS-MD.
> >>>>
> >>>> By what date are we shooting for a new draft spec?
> >>>>
> >>>>
> >>>
> >
>
>



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