OASIS Charter Submission Discuss

 
1. The TC apparently is not supposed to produce specifications, 
but
rather
"analysis, requirements" documents. Is there any reason for 
operating in
RAND terms (unless some future rechartering is expected, that 
will
produce actual specs)?


2. "Develop a requirement document for recommended Web Services 
(and
REST) extensions to address the Gaps ..."
It seems the requirement 
doc will go as far as "recommending extensions"
which means actually hinting 
at solutions, or at least defining the 
directions of future solutions?
Could then the nature of these 
"extensions" be better defined in the 
charter?
E.g. are we talking of 
(a) "profiling" or configuring existing SOA 
stacks for specific TEL use, or 
(b) developing specific WS on top of 
them, or 
(c) "extending" the functionality of these stacks with native functionality that goes beyond (a) and (b)? 

In other words, I see this as part of 
defining the scope of activities: what will be the technical
scope of the 
solutions implied by the requirements down the 
road?
My concern is: the scope of activity and deliverables should 
more explicitly allow for 
solutions outlines / directions (if not full fledge specifications of these solutions), as I guess 
at some point when
"requirements" meet concrete SOA environments (and 
concrete specs like WSDL, BPEL), 
the separation
between "requiremetns" from "solution outlines 
/ options" is 
blurred.


3. Audience for this TC:
"The output of this work will 
have direct benefits for the use of the
Web 2.0 and SOA in Telecom.  
"
Should this be interpreted that only Telecom professionals are 
invited
or will benefit? Could there be a line on possible interest from 
SOA
middleware providers, as this is about requirements for their 
products?

4. Scope of work: there is 1.a but not 1.b secion. Missing 
1.b?

On Nov 05, 2008, at 12:34 PM, Durand, Jacques R. wrote:

>
> 1. The TC apparently is not supposed to produce specifications, but
> rather
> "analysis, requirements" documents. Is there any reason for  
> operating in
> RAND terms (unless some future rechartering is expected, that will
> produce actual specs)?


yes. So i'm wondering exactly how it will produce anything but CD's.

  -jeff

>
>
>
> 2. "Develop a requirement document for recommended Web Services (and
> REST) extensions to address the Gaps ..."
> It seems the requirement doc will go as far as "recommending  
> extensions"
> which means actually hinting at solutions, or at least defining the  
> directions of future solutions?
> Could then the nature of these "extensions" be better defined in the  
> charter?
> E.g. are we talking of
> (a) "profiling" or configuring existing SOA stacks for specific TEL  
> use, or
> (b) developing specific WS on top of them, or
> (c) "extending" the functionality of these stacks with native  
> functionality that goes beyond (a) and (b)?
> In other words, I see this as part of defining the scope of  
> activities: what will be the technical
> scope of the solutions implied by the requirements down the road?
> My concern is: the scope of activity and deliverables should more  
> explicitly allow for
> solutions outlines / directions (if not full fledge specifications  
> of these solutions), as I guess at some point when
> "requirements" meet concrete SOA environments (and concrete specs  
> like WSDL, BPEL), the separation
> between "requiremetns" from "solution outlines / options" is blurred.
>
>
> 3. Audience for this TC:
> "The output of this work will have direct benefits for the use of the
> Web 2.0 and SOA in Telecom.  "
> Should this be interpreted that only Telecom professionals are invited
> or will benefit? Could there be a line on possible interest from SOA
> middleware providers, as this is about requirements for their  
> products?
>
> 4. Scope of work: there is 1.a but not 1.b secion. Missing 1.b?

--
Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware 				+1(650)506-1975
	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
Oracle								Redwood Shores, CA 94065

On Nov 05, 2008, at 12:34 PM, Durand, Jacques R. wrote:

>
> 1. The TC apparently is not supposed to produce specifications, but
> rather
> "analysis, requirements" documents. Is there any reason for  
> operating in
> RAND terms (unless some future rechartering is expected, that will
> produce actual specs)?
>
>
> 2. "Develop a requirement document for recommended Web Services (and
> REST) extensions to address the Gaps ..."

I also do not understand why this needs to be done under RAND mode.

I am concerned that there will be little market acceptance of  
encumbered standards that are fundamental to the SOA space.
Seems like this is breaking with the established mode of operation in  
the SOA space.
   -jeff

>
> It seems the requirement doc will go as far as "recommending  
> extensions"
> which means actually hinting at solutions, or at least defining the  
> directions of future solutions?
> Could then the nature of these "extensions" be better defined in the  
> charter?
> E.g. are we talking of
> (a) "profiling" or configuring existing SOA stacks for specific TEL  
> use, or
> (b) developing specific WS on top of them, or
> (c) "extending" the functionality of these stacks with native  
> functionality that goes beyond (a) and (b)?
> In other words, I see this as part of defining the scope of  
> activities: what will be the technical
> scope of the solutions implied by the requirements down the road?
> My concern is: the scope of activity and deliverables should more  
> explicitly allow for
> solutions outlines / directions (if not full fledge specifications  
> of these solutions), as I guess at some point when
> "requirements" meet concrete SOA environments (and concrete specs  
> like WSDL, BPEL), the separation
> between "requiremetns" from "solution outlines / options" is blurred.
>
>
> 3. Audience for this TC:
> "The output of this work will have direct benefits for the use of the
> Web 2.0 and SOA in Telecom.  "
> Should this be interpreted that only Telecom professionals are invited
> or will benefit? Could there be a line on possible interest from SOA
> middleware providers, as this is about requirements for their  
> products?
>
> 4. Scope of work: there is 1.a but not 1.b secion. Missing 1.b?

--
Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware 				+1(650)506-1975
	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
Oracle								Redwood Shores, CA 94065