RE: [opencsa-liaison] Namespace for bindings and other extension points (was: Latest/This Version URI for Schema/WSDL files)

Hi Simon,

 

I guess the LSC's guideline was not fully reflecting 
the underlying assumptions. Here are the key points (in my own words, and as I 
understand):

 

- The final version of all the SCA specifications will be 
tagged with a common version number (the current assumption is - 
1.1).

 

- Before all the TCs produce the final material (i.e. 1.1 
version):

 a> We will use a common namespace that will be 
owned by the SCA Assembly TC (ownership here loosely means coordinating across 
the different SCA TCs when a new revision of the common namespace is to be 
created, etc).

 b> If an SCA TC needs to introduce a backward 
incompatible change to the definitions in the common namespace, that TC notifies 
(via LSC) the Assembly TC to rev up the common namespace.

 

- It is only after the 1.1 version that we will try out the 
idea of using fine grained namespaces for temporarily managing the TC specific 
backward incompatible changes before merging the changes into the next revision 
of the common namespace.

 

I hope the above clarifies the intentions behind the 
guidelines and answers the questions in your email below. LSC members, please 
feel free to chime in.

 

-- Sanjay

  

  
  From: Simon Holdsworth 
  [mailto:] 
Sent: Friday, Jun 06, 2008 
  11:39 AM
To: Patil, Sanjay
Cc: Anish Karmarkar; Michael 
  Rowley; ; 
  
Subject: RE: [opencsa-liaison] 
  Namespace for bindings and other extension points (was: Latest/This Version 
  URI for Schema/WSDL files)

  

Sanjay, 

[please note I don't think I have permission to post to 
  the Liaison SC mailing list, so this message may not appear there] 
  

Thanks for circulating this. 
   Unfortunately I find several parts of the statement ambiguous. 
  

"and use the TC specific fine grained namespaces post 
  1.1" 

Are the fine grained 
  namespaces post 1.1 only used if the TC introduces incompatible 
  changes? 

Does the following 
  statement only apply post 1.1? 

"Whenever an incompatible change is to be made 
  to the schema, a new revision of the common namespace should be 
  generated" 

Does "post 1.1" refers to some specific single point in 
  time at which all TCs agree to have reached a 1.1 level? 

Given that fine-grained namespaces can be used post 
  1.1, why is there a necessity to generate a new revision of the common 
  namespace?  I was under the impression that the fine-grained namespace 
  could be used and revved for some period of time, until an agreed point was 
  reached where the updates would be folded back into a new revision of the 
  common namespace. 

So should that 
  statement actually be: 

Whenever an 
  incompatible change is to be made within a TC specific namespace, a new 
  revision of the TC-specific namespace should be generated. 
  

When the TC wants to update the version 
  of their schema in the common namespace and lose the TC-specific fine-grained 
  namespace for a major revision, that falls under the "Whenever an SCA TC decides to make an incompatible change which affects 
  the common namespace" part. 
  

Given all the above, I'd like to suggest 
  the following disambiguation: 

For defining 
  elements used in the SCDL file, all SCA TCs should start by using the common 
  namespace.  At a specific point in time version 1.1 of the common 
  namespace will be finalized.  After that time TCs may elect to use TC 
  specific fine grained namespaces when any incompatible change is to be made to 
  their schemas.  Following that, whenever an incompatible change is to be 
  made within a TC specific namespace, a new revision of the TC specific 
  namespace should be generated. Whenever an TC decides to make an incompatible 
  change which affects the common namespace, including updating the TC's schemas 
  in the common namespace and discarding one or more TC specific fine grained 
  namespace, that TC is obliged to inform all of the other SCA TCs, via the 
  OpenCSA Liaison Subcommittee - and that the Assembly TC is responsible for 
   coordinating the change where it affects multiple SCA 
  TCs.

Regards, Simon 
  

Simon Holdsworth
STSM, SCA Bindings 
  Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM UK 
  Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 
  245059) Fax +44-1962-816898
Internet -  
  

  
    
    

      "Patil, Sanjay" 
        <> 
        
06/06/2008 10:10 

      
        
          
          

            
              
To

            "Michael Rowley" 
              <>, "Anish Karmarkar" 
              <>, 
              <> 
          

            
              
cc

            <> 
          

            
              
Subject

            RE: [opencsa-liaison] Namespace 
              for bindings and other extension points (was: Latest/This Version 
              URI for Schema/WSDL files)

        
          
          

            
            

 
On 6/2/08 conf-call [1], the OpenCSA Liaison Subcommittee 
  resolved the
below issue with the following guideline:

For defining 
  elements used in the SCDL file, all SCA TCs should use the
common 
  namespace, and use the TC specific fine grained namespaces post
1.1. 
  Whenever an incompatible change is to be made to the schema, a new
revision 
  of the common namespace should be generated. Whenever an SCA TC
decides to 
  make an incompatible change which affects the common
namespace, that TC is 
  obliged to inform all of the other SCA TCs, via
the OpenCSA Liaison 
  Subcommittee - and that the Assembly TC is
responsible for coordinating the 
  change where it affects multiple 
  SCA
TCs.

[1]
http://lists.oasis-open.org/archives/opencsa-liaison/200806/msg00000.htm
l

Thanks,
Sanjay
Co-Chair, 
  OpenCSA Liaison Subcommittee

> -----Original Message-----
> 
  From: Michael Rowley [mailto:] 
> Sent: Tuesday, Mar 25, 
  2008 22:35 PM
> To: Anish Karmarkar; 
  
> Subject: [opencsa-liaison] 
  Namespace for bindings and other 
> extension points (was: Latest/This 
  Version URI for Schema/WSDL files)
> 
>  
> Good point 
  Anish.  I suspect that one of us was indeed 
> supposed to 
  bring
> this up (I don't recall who, if anyone, was identified). 
   So, 
> how about
> me.
> 
> Dear Liason 
  Committee,
> 
> The Bindings TC would like guidance on the 
  namespace to use for the
> various <binding.xxx> elements that it 
  is in charge of defining.
> Specifically, the question is whether the 
  bindings should 
> always use the
> same namespace as SCA 
  assembly, or whether they should each use
> different 
  namespaces.
> 
> The Bindings TC debated this question for a while 
  at its F2F, 
> but agreed
> that the approach taken should follow 
  a generally agreed approach that
> would also apply to all of the 
  extensibility points in SCA assembly
> (such as implementation elements 
  <implementation.xxx> and interface
> elements 
  <interface.xxx>).  As such, we think this is an appropriate
> 
  issue for the Liason group to tackle.
> 
> Argument 
  Kickstart:
> 
> At the F2F, we discussed the pros and cons of a 
  few approaches.
> 
> Each binding gets its own namespace:
> 
  - This approach allows each binding definition to evolve independently
> 
  from other binding definitions and independent of SCA as a whole.
> 
  
> Everything in one "SCA" namespace:
> - This approach gives the 
  user of SCA a set of technologies that are
> known to work together. 
   If each binding/implementation/etc evolved
> independently, then 
  the user would be hard pressed to figure out which
> collection of them 
  actually worked together.
> - Having one namespace means that there are 
  fewer prefixes to 
> define at
> the top of the various SCDL files 
  (this seemed to carry less 
> weight than
> the previous 
  point).
> 
> Both:
> - Perhaps it is possible to define 
  
> bindings/implementations/etc in their
> own namespace, but then 
  also create a overarching namespace 
> that brings
> together 
  "blessed" versions of each candidate technology.  XML Schema
> may 
  not have good ways of doing this (I don't know), but in the
> 
  worst-case, the element definitions could be repeated in a different
> 
  namespace.
> 
> No decision was made, but it was my impression 
  that the last of these
> approaches carried the greatest appeal, if the 
  details could be worked
> out.
> 
> Michael
> 
> 
  
> 
> -----Original Message-----
> From: Anish Karmarkar 
  [mailto:] 
> Sent: Tuesday, March 25, 2008 
  3:13 PM
> To: Michael Rowley
> Cc: Mike Edwards; 
  
> Subject: Re: [opencsa-liaison] 
  Latest/This Version URI for Schema/WSDL
> files
> 
> 
  Michael,
> 
> Since we are the liaison reps from binding, were we 
  (or was 
> I) supposed
> to do this?
> 
> 
  -Anish
> --
> 
> Michael Rowley wrote:
> > 
  +1
> > 
> > I don't think a meeting is necessary for this 
  one, but I 
> believe that 
> > the binding TC was looking for 
  input from the Liason committee 
> > regarding whether or not the 
  bindings should be in the SCA 
> namespace, 
> > a binding 
  specific namespace, or both.  I thought that someone from 
> > 
  Bindings was going to be formally asking the Liason committee to 
> > 
  provide a recommendation on that.
> > 
> > Michael
> 
  
> 
  ---------------------------------------------------------------------
> 
  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_workgr
> 
  oups.php 
> 
> 
  

---------------------------------------------------------------------
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 
  

  
  

  
Unless stated otherwise above:
IBM 
  United Kingdom Limited - Registered in England and Wales with number 741598. 
  
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
  3AU