Chiusano Joseph wrote:
> Thanks Farrukh. I will draft something over the weekend and send. I
> will take all perspectives into account (all are valuable), which will
> include the perspective of the needs of the US federal space as well
> as our TC members, to make sure that all needs are accounted for. Once
> submitted, we can vet the exact text within the TC collaboratively.
Hi Joe,
Maybe you missed it but Kathryn suggested we keep it simple. So I cut
out that section for most part. I think we are all set on that
deliverable now. Thanks.
>
> Joe
>
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com <http://www.boozallen.com/>
>
>
> ------------------------------------------------------------------------
> *From:* Farrukh Najmi [mailto:]
> *Sent:* Thursday, March 10, 2005 10:40 AM
> *To:*
> *Subject:* Re: [regrep] [Draft] Statement of relationship with
> other standards
>
> Chiusano Joseph wrote:
>
>> I would like to recommend that we also include information
>> regarding how the 2 registry standards can be used together in a
>> complementary manner, as described in 2 articles that I had
>> published in April 2003 and September 2003 respectively:
>>
>> http://www.mywebservices.org/index.php/article/articleview/984/1/24/
>> http://www.ebxmlforum.org/articles/ebFor_20030824.html
>>
>> Speaking for the US federal government space, this type of
>> information would be extremely valuable as there is much
>> confusion within that space regarding UDDI vs. ebXML Registry
>> that can be clarified further by including this type of
>> information (i.e. in addition to the information below). Also,
>> there is a high probability that in the future the US federal
>> government space could see UDDI and ebXML registries interacting
>> with one another.
>>
>> If anyone believes this is not a good idea, please express
>> concrete reasons as to why it would not be.
>
> Thanks for the valuable suggestion Joe.
>
> Would you like to propose some concrete text that we can consider?
> I would suggest keeping it very brief (ideally a couple of sentences)
> since we dont want this to become a paper about UDDI and ebXML
> Registry.
>
> As a suggestion I propose the use case where a UDDI registry
> references
> an artifact in ebXML Registry within its overviewDoc/overViewURL
> using the ebXML Registry HTTP binding.
>
> Rspectfully, the following use cases are ones I feel we MUST NOT
> mention and I include my
> reasons why below:
>
> "Using UDDI to find ebXML Registry/Repository"
>
> This use case implies that one needs UDDI to find an ebXML
> Registry and
> that somehow ebXML Registry is dependent on UDDI for this. Why cant
> an ebXML registry be discovered in another ebXML Registry. More likely
> why cant it just get discovered by a google serach. This use case
> is not realistic.
> I am not aware of any instances of this use case and do not feel
> it solves a real
> problem.
>
> "UDDI as the registry for ebXML Components"
>
> This use case has nothing to do with ebXML Registry - UDDI interop.
> So I feel that it has no relevance in this context.
>
> Thanks again for your valuable comments.
>
>
>>
>> Thanks,
>> Joe
>>
>> Joseph Chiusano
>> Booz Allen Hamilton
>> Visit us online@ http://www.boozallen.com <http://www.boozallen.com/>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Farrukh Najmi [mailto:]
>> *Sent:* Thursday, March 10, 2005 9:27 AM
>> *To:*
>> *Subject:* Re: [regrep] [Draft] Statement of relationship
>> with other standards
>>
>> Dear colleagues,
>>
>> Here is the revised text based on Monica's excellent
>> suggestions for your convenience. I have incorporated almost
>> all her suggestions with the exception of thos noted in my
>> previous response to her message. Please comment on this
>> revised version that follows...
>>
>> As Kathryn mentioned, in order to submit our specs for OASIS
>> standardization process next week we need
>> a statement of relationship of our specs with other
>> standards. Per my ACTION from previous meetings I am
>> providing the draft text below.
>>
>> Please share comments on this thread. Thanks.
>>
>> <draft text>
>>
>> [3.] A statement regarding the relationship of this
>> specification to similar work of other OASIS TCs or other
>> standards developing organizations.
>>
>> The OASIS ebXML Registry 3.0 specifications are aligned with
>> a variety of other OASIS standards as described below.
>>
>> * The OASIS Web Services Security: SOAP Message Security
>> 1.0 specification is used to provide Message Security
>> for the Registry protocol.
>> * The OASIS Web Services Security: SOAP Message with
>> Attachments (SwA) Profile 1.0 specification is used to
>> provide Message Security for SOAP attachments within
>> the Registry protocol.
>> * The OASIS XACML 1.0 specification is used to define the
>> syntax for registry Access Control Policies.
>> * The OASIS SAML 2.0 specifications are used to support
>> Federated Identity Management and Single Sign On within
>> the registry
>>
>> The OASIS ebXML Registry 3.0 specifications have some
>> similarities with the OASIS UDDI 3.0 standard in that both
>> specifications define a registry standard.
>> Both specifications define a registry that is a web service.
>> Both specifications define a registry that may be used as a
>> registry for web services.
>> The two specifications have been independently developed and
>> neither specifications uses the other as a dependency.
>>
>> Limited similarities exist between the OASIS ebXML Registry
>> 3.0 and OASIS UDDI 3.0.
>> Both specifications define a registry for web services and a
>> registry exposed as a web service.
>> No explicit dependencies exist between the two OASIS
>> specification efforts. UDDI 3.0 specifies a registry only,
>> while ebXML Registry 3.0 specifies both a registry and a
>> repository. Other unique and value-added features of OASIS
>> ebXML Registry 3.0 include:
>>
>> * Custom domain specific artifact discovery queries using
>> SQL-92 and XML Filter Query syntax
>> * Parameterized registry-resident (stored) queries
>> * Life cycle management and artifact governance including
>> automatic version control
>> * Content based event notification using domain specific
>> queries
>> * User-defined, domain specific, taxonomies
>> * Domain specific custom relationships between artifacts
>> * Ability to group related artifacts in packages
>> * Automatic content specific content validation and
>> cataloging
>> * Federated queries across multiple registries
>> * Linking artifacts across registries
>> * Federated identity and single sign on support based on
>> SAML v2.0
>> * HTTP Binding to registry protocol
>> * Extensible API and protocol
>>
>>
>> </draft text>
>>
>> BTW, I would like to also include features in UDDI 3.0 that
>> are not provided by ebXML Registry 3.0. My reading of the
>> UDDI 3.0 specs
>> returned no such candidate items. Paul since you are a member
>> of UDDI TC could you take an ACTION to provide us with a list
>> of UDDI 3.0 features
>> that ebXML Registry 3.0 does not support? It would be good to
>> state the features in terms of end user relevant
>> functionality rather than something like
>> "UDDI has tModels and ebXML Registry does not". Thanks in
>> advance for your help.
>>
>>
>>
>>--
>>Regards,
>>Farrukh
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional
>> commands, e-mail:
>>
>
>
>--
>Regards,
>Farrukh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
--
Regards,
Farrukh
