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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: Follow-ups

I was reviewing previous e-mails, and wanted to follow-up on a few items.

We had and e-mail string with Paul regarding the Technical Note on UDDI as a registry for ebXML components.  From the last e-mail, it appears that his questions were addressed (see attachment), but I wanted to verify that we covered his concerns.  

Paul, from the e-mail string, it looked like you asked for input on specific items - Taxonomy (or common language in the various ebXML specs, specifically ebMS and ebXML CPPA) and the overviewURL element for linking to an ebXML location.  The concluding e-mail from you lists two steps: 1) make ebMS and CPPA TCs aware of the technical note and get feedback on how their specs were represented, and 2) taking the larger issue of a coordinated ebXML taxonomy (or vocabulary) to the Joint Committee to address.  The question on the overviewURL element was addressed with the recommendation that the TN refer to the latest version of each spec.  Does this accurately summarize the issues and resolutions?  Do you need any further input from us?  Please let me know if we need to add this to the agenda for our next telecon.
 <<RE: [regrep] Meeting reminder and agenda>> 
The XML Schema issue e-mail string stopped with a question, so I wanted to follow-up on that to see if it is resolved.  This is the one that recommended replacing choice with type substitution.  Monica had recommended that an iterative approach might be an option (see attachment).  Is this one resolved?  Does it need to be added to the agenda for our next telecon?
 <<Re: [regrep] [XML Schema issue] Replace choice with type substitution>> 
The last one I wanted to follow-up on is the One RegistryObject - Many ACPs proposal.  Farrukh presented two options, recommending the second one (see attachment).  Any additional input on this?  Does it need to be added to the agenda for our next telecon? 
 <<Re: [regrep] One RegistryObject - Many ACPs proposal>> 
Thanks!
Kathryn


Kathryn Breininger
CENTRAL Project Manager
Emerging Technologies
Boeing Library Services

425-965-0182 phone
425-237-3491 fax
kathryn.r.breininger@boeing.com



I agree with you.  The first will require a minimal understanding of how
tModels are design/built/expressed within UDDI and how simple taxonomies
can be expressed.  I wish you all the luck in the world.  This is a key
endeavor.

Joel Munter, Intel
desk: 480.552.3076
cell:  602.790.0924
 

-----Original Message-----
From: MACIAS, Paul [mailto:PMACIAS@lmi.org] 
Sent: Thursday, March 06, 2003 10:53 AM
To: Munter, Joel D; Breininger, Kathryn R; Chiusano Joseph
Cc: ebXML Regrep (E-mail)
Subject: RE: [regrep] Meeting reminder and agenda

Joel,

There may be two tracks here.  Maybe a way to address all concerns is:
 1) make ebMS and CPPA TCs aware that UDDI has developed the TN and they
would appreciate their analysis of how their specs were represented.
 2) the larger issue of a coordinated ebXML taxonomy is brought to the
Joint Committee to consider.

Paul

-----Original Message-----
From: Munter, Joel D [mailto:joel.d.munter@intel.com]
Sent: Thursday, March 06, 2003 12:17 PM
To: MACIAS, Paul; Breininger, Kathryn R; Chiusano Joseph
Cc: ebXML Regrep (E-mail)
Subject: RE: [regrep] Meeting reminder and agenda




I think that you are making more of this than is required right now.  In
summary, review the UDDI TN ebXML taxonomy that is proposed and see if
Kibakura-san and the TN editors got it right.  Please note, these are
folks that want to see ebXML components and services get registered.
Albeit in UDDI registries, this is still in your best interest.

Joel Munter, Intel
desk: 480.552.3076
cell:  602.790.0924
 

-----Original Message-----
From: MACIAS, Paul [mailto:PMACIAS@lmi.org] 
Sent: Thursday, March 06, 2003 10:12 AM
To: Breininger, Kathryn R; Chiusano Joseph
Cc: ebXML Regrep (E-mail)
Subject: RE: [regrep] Meeting reminder and agenda

Kathryn,

Thanks.  I'll try that angle.

Paul

-----Original Message-----
From: Breininger, Kathryn R [mailto:kathryn.r.breininger@boeing.com]
Sent: Thursday, March 06, 2003 12:03 PM
To: Chiusano Joseph; MACIAS, Paul
Cc: ebXML Regrep (E-mail)
Subject: RE: [regrep] Meeting reminder and agenda


Paul,
You could bring it up to the ebXML Joint Committee to address some of
the cross issues if you want, but you should be very specific about what
you want them to address.  I believe the current Chair is Colleen Evans
(rotates quarterly).

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Thursday, March 06, 2003 8:55 AM
To: MACIAS Paul
Cc: Breininger, Kathryn R; ebXML Regrep (E-mail)
Subject: Re: [regrep] Meeting reminder and agenda


That's ok Paul. That's why I'm trying to help.

I think this should be done simply by referring to the latest version of
each spec, whether they are under OASIS or UN/CEFACT. I personally don't
see any need for you to "get the issue in front of other ebXML TC's" if
all you are trying to do is verify the definitions in the UDDI document.

As for a consistent ontology between specifications, I personally see
that as an issue that (with all due respect) is outside of your scope,
and should be raised to the propery "higher authorities".  I would
recommend you do that as soon as possible, and step out of the way. :)

Joe

"MACIAS, Paul" wrote:
> 
> Yeah, sorry for confusion.  I should have been better at reviewing my
responses.  Just hope I eventually got there.  :)
> 
> I agree that this is an issue beyond any one ebXML community.  I
really think that UDDI intended for me to go to MS and CPPA and see if
they agree on things like the definitions (2.1) and the concepts that
represent their specs in parts like 2.2.3 and 2.2.4 .  Which I do intend
to do.  But, I think the coordination of ebXML concepts that have
representations among various ebXML TC specs (and in other OASIS TCs as
UDDI is doing) helps to reinforce the concepts in all the
specifications.
> 
> I do not participate in any of the other ebXML TCs so I'm trying to
get the issue in front of them.  Any recommendations on how I should go
about it would be greatly appreciated.
> 
> Thanks,
> 
> Paul
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Thursday, March 06, 2003 11:17 AM
> To: MACIAS, Paul
> Cc: Breininger Kathryn R; ebXML Regrep (E-mail)
> Subject: Re: [regrep] Meeting reminder and agenda
> 
> That's completely different than what I conveyed from your original
> request. ;)
> 
> As you know, "language" is such a broad term - specific, concrete
> examples from the UDDI document and their relevance to this issue
would
> be very helpful.  It's also possible that this issue is for a "higher"
> committee to consider - such as one of the joint committees - as it
> involves cross-TC issues.
> 
> Joe
> 
> "MACIAS, Paul" wrote:
> >
> > I'm using namespace in the sense of an area for managing registered
objects, not the technical namespace.  So don't look for a technical
representation of "namespace". If that's still confusing just ignore it,
because it's not the core issue.
> >
> > The point is that UDDI would like to to know whether their language
properly represents language from the ebXML specifications.  Now, the
owning ebXML TCs can and should make that analysis to ensure the intenet
of their specifications is acurately reflected.  But I thought (hoped)
that there has been some coordination on common language between ebXML
Reg/Rep and the other ebXML specification that we could still provide a
set of eyes to consider that part of the UDDI request.  Such an exercise
would help insure that our own specification properly aligns in language
used by the other TCs.  I'm not talking about using the same glossary
(though I think that should be the case IMHO.)  Rather, think about how
we have rolled in ebMS and ebXML CPPA and see if we are all being
consistant.  Does that make sense?  Seem worth while?
> >
> > Thanks,
> >
> > Paul
> >
> > -----Original Message-----
> > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > Sent: Thursday, March 06, 2003 10:44 AM
> > To: MACIAS, Paul
> > Cc: Breininger Kathryn R; ebXML Regrep (E-mail)
> > Subject: Re: [regrep] Meeting reminder and agenda
> >
> > Thanks - please see below.
> >
> > <Quote>
> > The UDDI TC would like ebXML community validate,
> >   1) the naming conventions used to identify the ebXML namespace
aligns
> > with ebXML conventions, and
> >   2) the URLs in the overviewURL elements are correct.
> > </Quote>
> >
> > Regarding (1) - Still unclear what you mean. There is no mention of
> > namespace in this entire document. Also what are "ebXML conventions"
for
> > namespaces? None exist as far as I know.
> >
> > Regarding (2) - Can't this simply be done by verifying the URL in a
> > browser (i.e. anyone can do this)? Perhaps the UDDI folks mean
something
> > else?
> >
> > If it would help, perhaps you can have an additional UDDI TC member
> > clarify this request for us so we don't keep going around in
circles.
> > Don't mean to be harsh, just that business is business.
> >
> > Joe
> >
> > "MACIAS, Paul" wrote:
> > >
> > > Joe,
> > >
> > > Certainly.  The paper focuses on explaining how a to implement
registration of web services based on ebXML CPPA activities. The paper
proposes a taxonomy for ebXML specifications.  However, UDDI believes
that the ebXML community is the proper owner of such a taxonomy and
changed the tModel Keys to create an ebXML namespace if you will.
> > >
> > > Sections 2.2.3 & 2.2.4 define the ebXML related tModels. You'll
see in schema an "overviewURL" element that is intended to link to a
ebXML location for the framework/specification related to the tModel.
> > >
> > > The UDDI TC would like ebXML community validate,
> > >   1) the naming conventions used to identify the ebXML namespace
aligns with ebXML conventions, and
> > >   2) the URLs in the overviewURL elements are correct.
> > >
> > > There is not an ebXML Reg/Rep spec involved in the UDDI paper, so
the second issue really is something for other ebXML TCs to validate.
But we may want to consider the first issue on ebXML naming conventions.
I am in the process of trying to get these questions in front of the
ebXML MS and CPPA TCs as well.
> > >
> > > If there is any questions or comments, please let me know.
> > >
> > > Thanks,
> > >
> > > Paul
> > >
> > > -----Original Message-----
> > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > > Sent: Thursday, March 06, 2003 10:04 AM
> > > To: MACIAS, Paul
> > > Cc: Breininger Kathryn R; ebXML Regrep (E-mail)
> > > Subject: Re: [regrep] Meeting reminder and agenda
> > >
> > > Paul,
> > >
> > > <Quote>
> > > the TC would like our input on a Namespace and URLs associated
with
> > > the Note.
> > > </Quote>
> > >
> > > Regardless of whether or not we have the opportunity to discuss
this on
> > > the call today, I would recommend that you provide more details on
such
> > > requests when you present them to the listserv. That will help
spark
> > > discussions that can be very valuable in the time leading up to
our
> > > discussions on a call.  It would also help us better prepare to
offer
> > > points of view.
> > >
> > > I am very familiar with this paper, having read a preliminary
version of
> > > it. However, I'm not sure what you mean by Namespaces and URLs.
Please
> > > provide more details.
> > >
> > > Respectfully,
> > > Joe
> > >
> > > "MACIAS, Paul" wrote:
> > > >
> > > > Kathryn,
> > > >
> > > > If time permits I'd like to add a discussion item I'm bringing
forward from UDDI.  The UDDI TC is preparing a Technical Note on UDDI as
a registry for ebXML components, and the TC would like our input on a
Namespace and URLs associated with the Note.  The document is undergoing
some editing, but I've attached a recent version.
> > > >
> > > > Thanks,
> > > >
> > > > Paul
> > > >
> > > > -----Original Message-----
> > > > From: Breininger, Kathryn R
[mailto:kathryn.r.breininger@boeing.com]
> > > > Sent: Wednesday, March 05, 2003 4:57 PM
> > > > To: ebXML Regrep (E-mail)
> > > > Subject: [regrep] Meeting reminder and agenda
> > > > Importance: High
> > > >
> > > > This is a reminder of our ebXML Reg/Rep telecon tomorrow, March
6th, at 1:30 pm Pacific Time.  This is our regular bi-weekly telecon,
and is scheduled from 1:30-3:30.  Call in information is below:  (pass
code is correct!)  Joe may not be available for this telecon due to a
conflict, so we will postpone his items until next time if he is not on
the line.
> > > >
> > > > USA domestic toll free number: 1-866-235-8350
> > > > Pass code: 669014#
> > > > Here is the phone number for the operator if you have any
problems:
> > > > 206-655-2254.
> > > >
> > > > Agenda:
> > > > 1. Minute taker
> > > > 2. Approval of minutes from last meeting (correction)
> > > > 3. Status on specs, review of changes (chapter 12, Generic
Header, Users and Organizations, etc.)
> > > > 4. Namespace discussion - any resolution?
> > > > 5. Review of action items for spec
> > > > 6. Position paper update
> > > > 7. OASIS Forum on the Direction of Web Services - Report out
> > > > 8. Discussion on CCTS implementation in Registry (if Joe is
available)
> > > > 9. Best Practice Paper (if Joe is available)
> > > > 10. Other issues/items
> > > > 11. Next meeting
> > > >
> > > > Please let me know if there are additional items you would like
added to the agenda.
> > > >
> > > > Thanks.
> > > >
> > > > Kathryn Breininger
> > > > CENTRAL Project Manager
> > > > Emerging Technologies
> > > > Boeing Library Services
> > > >
> > > > 425-965-0182 phone
> > > > 425-237-3491 fax
> > > > kathryn.r.breininger@boeing.com
> > > >
> > > > ----------------------------------------------------------------
> > > > To subscribe or unsubscribe from this elist use the subscription
> > > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> > > >
> > > >
------------------------------------------------------------------------
> > > >                                                      Name:
uddi-spec-tc-tn-uddi-ebxml-20030227.doc
> > > >                                                      Type:
Microsoft Word Document (application/msword)
> > > >    uddi-spec-tc-tn-uddi-ebxml-20030227.doc       Encoding:
BASE64
> > > >                                               Description:
uddi-spec-tc-tn-uddi-ebxml-20030227.doc
> > > >                                           Download Status: Not
downloaded with message

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



If these type changes are made, would it create any confusion in the
developer community (differ design options used) and in adoption?

Although an iterative approach that minimizes the adoption impact would be a
good option.

Monica

Farrukh Najmi wrote:

> Farrukh Najmi wrote:
>
> >
> > Team,
> >
> > In new V3 schema we have consistently used type substitution instead
> > of choice construct when defining XMl schema. Choice in the pinion of
> > many is not very object oriented and implementation experience has
> > shown that it complicates design.
> >
> > I would like to ask if any one has objections if we replace
> > occurrences of <choice> in the schema with type substitution.
>
> To investigate this issue further I went ahead and removed choices from
> rim.xsd and query.xsd to see the full impact.
>
> It appears that modifying rim.xsd has relatively minor backward
> compatibility impact. However, the choice removal in query.xsd impacts
> Filter query schema in a major way. Although. the result is a much nicer
> filter query schema, the choice removal in query.xsd would create a huge
> burden on implementations as they will have to redo their implementation
> of Filter Query support.
>
> As an implementor of ebXML Registry I am OK with this but I suspect not
> every implementation would feel that way.
>
> Another consideration is that in V4 we may well support XQuery and
> deprecate Filter query.
>
> All this makes me wonder if the right thing may be to remove choices in
> rim.xsd (minor impact) and not remove choices in query.xsd (major impact
> to Filter query).
>
> Thanks for your thoughts.
>
> --
> Regards,
> Farrukh






Chiusano Joseph wrote:

>I like this idea very much (of course).  I also prefer Beethoven. :)
>
>Regarding the following:
>
><Quote>
>We need precedence rules for how the 4 sets play together. On this last 
>point I am thinking some more and discussing with some experts.
></Quote>
>
>Perhaps we can weave in the idea of Preference Indicators for
>associations, as in my last message.  This would allow one to simply
>indicate a hierarchy of preference based on their own criteria (which
>may involve preference of the SO's ACP over the RO's ACP, or vice-versa,
>etc.)
>
Uday and I spoke at length with Seth Proctor who is the lead for Sun's 
XACML open source implementation about how to define precedence rules 
defining how the 4 sets (Registry, User, SO, RO) of policies play together.

His suggestion was to simply use XACML and its combiningAlgorithm 
capabilities. The upshot of the discussion is that we should have 
exactly one XACML PolicySet for a RegistryObject (the way things are 
today) and allow that PolicySet to compose by reference, any/all of the 
Policy/PolicySet from the 4 sets (Registry, User, SO, RO). This allows 
the creator of the ONE super PolicySet to:

1. Define a tree where each node is a Policy or PolicySet belong   to 
one of 4 sets (Registry, User, SO, RO)

2. decide precisely what combiningAlgorithms (denyOverrides, 
permitOverrides, onlyOneApplicable, firstApplicable, or even a custom 
one) to use when combining the policy decisions from sibling nodes at a 
given level in the tree.

The result is maximum flexibility.

Given this information we have two choices:

1. Retain our current accessControlPolicy attribute in RegistryObject

2. Allow a RegistryObject to have zero or one ACP associated with it via 
an Association. More efficient storage wise.

I would recommend (2) which means we do all the changes I proposed in 
this thread but with the constraint that there will be only one node 
associated with a RegistryObject. If there are more than one then most 
recent one would be used.

Does this sound reasonable closure on this issue?

BTW in case you are wondering how come all these issues popping up 
now... As Nikola and I are wrapping up the final details on XML Schema, 
Filter Query, SQL schema etc. , we are finding little fit and finish 
issues. Rather than batching the issues fo the next meeting we are 
trying to get them resolved via email so we can reach closure on the 
spec work.

-- 
Regards,
Farrukh




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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