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

 


Help: OASIS Mailing Lists Help | MarkMail Help

opencsa-liaison message

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


Subject: RE: [opencsa-liaison] Next LSC conf-call?



Based on the responses received so far, it seems that we will be able to
achieve quorum for the LSC meeting on 6/2. In addition, I think the SCA
Bindings TC has been waiting for the LSC's resolution on the issue
related to 'Namespace for bindings and other extension points' [1]. I
think we should have the 6/2 conf-call. I will send out the agenda email
through Kavi soon.

-- Sanjay

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

> -----Original Message-----
> From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
> Sent: Thursday, May 22, 2008 9:53 AM
> To: opencsa-liaison@lists.oasis-open.org
> Subject: [opencsa-liaison] Next LSC conf-call?
> 
>  
> Monday, May 29th is a US holiday and I think we agreed to 
> cancel the LSC
> conf-call on that day.
> 
> For the LSC conf call in the following week (on Jun 2nd), some members
> had expressed concerns that the meeting time may confect with their
> travel plans for attending the SCA Assembly/Policy F2F in Germany.
> 
> I would like to get an idea of who can (not) attend the call 
> on Jun 2nd
> (at 8 AM Pacific Time / 5 PM in Germany). I can attend this call as I
> would have already reached the hotel by the time of this call.
> 
> -- Sanjay
> 
> > -----Original Message-----
> > From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
> > Sent: Thursday, May 22, 2008 9:46 AM
> > To: opencsa-liaison@lists.oasis-open.org
> > Subject: [opencsa-liaison] Minutes of the LSC conf-call on 5/19
> > 
> > 1. Roll Call
> >    Simon Nash, Bryan Aupperle, Martin Chapman, Anish 
> Karmarkar, Sanjay
> > Patil, Mike Edwards, Jeff Mischkinsky
> > 
> > 2. Scribe Assignment
> >    Sanjay
> > 
> > 3. Approval of minutes of 5/12/2008
> > http://lists.oasis-open.org/archives/opencsa-liaison/200805/ms
> > g00015.htm
> > l
> >    Approved
> > 
> > 4. Agenda Bashing
> >    Approved
> > 
> > 5. Issues
> > 
> > a. Namespace for bindings and other extension points
> > http://lists.oasis-open.org/archives/opencsa-liaison/200804/ms
> > g00010.htm
> > l
> > Discussion thread:
> > http://lists.oasis-open.org/archives/opencsa-liaison/200805/ms
> > g00009.htm
> > l
> >    Lot of discussion happened but no decisions were made. See 
> > below for
> > the raw chat log.
> > 
> > b. Use of Schematron in SCA Specifications
> > http://lists.oasis-open.org/archives/opencsa-liaison/200804/ms
> > g00006.htm
> > l
> > Discussion on 5/5 conf-call:
> > http://lists.oasis-open.org/archives/opencsa-liaison/200805/ms
> > g00013.htm
> > l
> >    Did not discuss due to lack of time
> > 
> > 
> > 6. Next Call Schedule
> >    May 29th is US holiday
> >    Jun 2nd may conflict with travel plans of members for 
> attending SCA
> > Assembly/Policy F2F meetings
> >    Next conf-call schedule to be discussed via email
> > 
> > 7. AOB
> >    None
> > 
> > 
> > -----------------------------
> > Raw chat log:
> > 
> > anish: i see the two as orgthogonal
> > anish: the two being compatibility and NS
> > 
> > Mike Edwards: These questions alone drive me to favour as few 
> > namespaces
> > as possible
> > Mike Edwards: anything else rapidly becomes a nightmare
> > 
> > Martin C: i think last week we said no more then 5 namespaces (ish)
> > would be a nightmare
> > 
> > Mike Edwards: > 1 is already a problem
> > Mike Edwards: assuming they ever get used together
> > 
> > Martin C: 1 namespace is a problem
> > 
> > Mike Edwards: ;-)
> > 
> > Martin C: for evolution
> > 
> > anish: even if we move in lock step, we'll likely get > 1 
> namspace and
> > will have to deal with it
> > 
> > Martin C: agreed
> > 
> > Mike Edwards: Just look at WSDL  & BPEL - very few 
> revisions and even
> > they cause problems
> > 
> > anish: sanjay, your proposal is interesting (what to do 
> before 1.1 --
> > keep the same NS regardless of what changes we make, these 
> are interim
> > revisions)
> > anish: i remember, during the schema 1.1 days, the W3C CR, PR and
> > Recommendation had 3 different namespaces and it was a 
> disaster, till
> > all the tools moved to the Recommendation
> > 
> > Sanjay: yes, the interim versions would just be 
> > work-in-progress in that
> > approach
> > Sanjay: the assumption being that we (OpenCSA MS) finish our work in
> > reasonable timeframe
> > 
> > Mike Edwards: Anish - it's that sort of thing that worries me a lot
> > Mike Edwards: I really don't know who we are helping here
> > 
> > anish: mike, right, that is why i think sanjay's proposal 
> is promising
> > anish: ... we say that interim versions are just that
> > 
> > Sanjay: the early implementors can clarify their support by 
> > pointing to
> > concrete artifacts (e.g. schema files)
> > 
> > anish: ... no change in NS regardless of whether the changes 
> > in the spec
> > are compatible or not
> > anish: so, regardless of whether we have fine grained or 
> lock-step, we
> > have one namespace for assembly 1.1 through out it's life
> > 
> > Mike Edwards: yes, everything before 1.1 final publication could
> > potentially break stuff from month to month (from CD to CD)
> > Mike Edwards: it's not nice, but trying to provide this "changing
> > namespace" solution is a bigger nightmare
> > 
> > anish: if we move lock-step then one NS for all specs for 1.1. If we
> > don't move lock-step then some 3-5 namespaces for 1.1
> > 
> > Mike Edwards: I think that we should aim to go "final" with 1 
> > namespace
> > 
> > anish: so again, i think there are two separate issues: 
> compatibility
> > and whether we rev NS for versions before 1.1 and lock-step v.
> > fine-grained
> > anish: i said before that we make compatibility stmt, i 
> think maybe we
> > need to do this only for different final versions (1.1, 
> 1.2, 2.0 ...)
> > 
> > Martin C: im not sure where/why substitution groups got introduced
> > 
> > anish: mike r, i think u are right wrt SG, but I think that 
> > is a general
> > problem with SG and why maybe it is not a good idea to use them
> > anish: substitution group's type is a QName not a list of 
> > QNames, so it
> > has to be only one
> > 
> > Sanjay: michaleR: all OpenCSA TCs use the common namespace 
> > and use fine
> > grained namespaces post 1.1
> > 
> > anish: scdl has a nice ring to it
> > 
> > Sanjay: For elements used in SCDL file, all SCA TCs use the common
> > namespace and use fine grained namespaces post 1.1
> > Sanjay: s: MikeEdwards
> > 
> > anish we're not going to have time to finish this
> > 
> > Mike Edwards: we're going to have to table this discussion
> > 
> > Sanjay: amendment by SimonNash: Whenever an incompatible 
> > change is made
> > to the schema, a new rev of namespace is to be generated
> > Sanjay: seconded by Martin
> > 
> > Meeting adjourned due to running out of time.
> > 
> > 
> ---------------------------------------------------------------------
> > 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_workgr
> oups.php 
> 
> 


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