Re: [regrep] ebXML Registry and Content Management (was Re: [regrep] Meeting agenda and reminder for ebXML Registry telecon December 18th, 2003)

["David RR Webber" <david@drrw.info>]

Duane,

You raise some interesting points - and I agree that the old ebXML
architecture document did its job for 1.0 - but I'm not sure that
we necessarily need a new ebXML Architecture specification and team.

Instead - I'm more interested in focusing on best-practices and proven
solution configurations - as we just saw with the CDC pilot for XML2003.

And here in lies the rub - can anyone person/team create an authoritative
"ebXML
Architecture?"    Instead - ebXML has advanced to where it can be
used in multiple roles and deployments - and outgrown the original limited
(design time only) thinking - to become a fully fledged set of technology
components - where the key thing is the proven integration and
interoperability.

That's why I'm see at this point - its much more useful for people to know
how to use a suite of OASIS specifications together - like CDC, like
AutoTech,
and many more real implementations today are proving.

Perhaps the IIC or the TAB are other possible venues - where such a
sub-team can be initiated - to manage and Q&A such solution sets - and
then publish them as case studies?

I think that would be much more productive at this stage - for adopters
and implementers of ebXML based solutions.

Thanks, DW.

----- Original Message ----- 
From: "Duane Nickull" <dnickull@adobe.com>
To: "Breininger, Kathryn R" <kathryn.r.breininger@boeing.com>
Cc: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM>; "Collins, Jeff"
<jcollins@vignette.com>; "ebXML Regrep (ebXML Regrep)"
<regrep@lists.oasis-open.org>
Sent: Friday, December 19, 2003 6:26 PM
Subject: Re: [regrep] ebXML Registry and Content Management (was Re:
[regrep] Meeting agenda and reminder for ebXML Registry telecon December
18th, 2003)


> To add to Kathryn's email, I must also express the architectural
> viewpoint from ebXML.
>
> The ebXML Technical Architecture team had a responsibility to map the
> user requirements to an architecture that could be implemented using
> several components.  The Service Oriented architecture uses the ebXML
> Registry as one of its' components to facilitate a set of functional
> requirements described in normative sections of the ebXML TA v 1.04.
>  ebXML Registry currently meets all of those functional requirements
> plus has started adding in functionality that is needed, yet was never
> specified within the TA 1.04.  This is a byproduct of two items:
>
> 1. The ebXML Technical Architecture v 1.0 is out of date and needs to be
> revised and be reconciled with advances made by all ebXML groups and
> also needs to include certain web service standards (WSDL and SOAP as
> well as optionally UDDI - the latter being a point for discussion).
>
> 2. Advances in implementors requirements that are not part of the ebXML
> Requirements document v 1.06.  As time changes, so do the requirements
> of users.  The ebXMl Requirements document could be updated too.
>
> To rectify this, I am proposing a new ebXML Technical Architecture team
> be established and a new revision of the architecture be written.  I
> would also like to suggest that a revision to the ebXML Requirements
> document be done to update that documents.
>
> I would also like to see the following for ebXML as a whole:
>
> 1. Coordinated meetings between all ebXML and relevant WS branded TC's
> 2. Tighter control over versioning of the specifications and a
> architecture/versioning scheme that can be implemented.  (I am thinking
> that if everyone aims at making version 3.0 the gold / real copy, we can
> achieve this based on lessons learned).
> 3. Integration of Web services standards formally within ebXML (Registry
> already has WSDL and SOAP, ebXML MS has SOAP but we can also use UDDI
> optionally to facilitate dynamic discovery of other web service within
> an ebXML architecture instance.)
> 4. Implementation profiles and an implementation guide published
> (perhaps by IIC?).
> 5. Inclusion of UBL as a start payload format for ebXML.  One thing that
> many implementors found annoying was the lack of a specific payload.
>  While we cannot constrain ebXMl to use only UBL, it may be good to have
> it as a starting point.
> 6. Someone to set up and maintain a production registry as a Registry
> Zero, to start the federation.
> 7. World peace
> (The latter one I personally added since I am already asking for so much
> and I figured it was best to ask for everything in one go)
>
> I'm sure this will invoke some other opinions.  I wouldn't mind moving
> this thread to the ebXML Dev list under the title "ebXML Future"
>
> Duane Nickull
> Breininger, Kathryn R wrote:
>
> >I would like to insert a brief clarification here.  In a couple of the
> >recent e-mails in this string there have been references to ebXML
> >Registry specs as Content Management Standards.  As I stated in our
> >telecon yesterday, I believe our intention (ebXML Registry TC) is that
> >the ebXML Registry specs and standards support and enable content
> >management, not that the ebXML Registry specs become the definitive
> >Content Management System standards.  Generally speaking, a Content
> >Management System includes authoring, check-in/check-out, workflow,
> >versioning, etc.  An ebXML Registry has broader application in its
> >enabling of ebusiness, federation features, classification support,
> >interoperation with other OASIS and ebXML standards, and additional
> >services, most of which can compliment a CMS.
> >
> >We need to bear in mind our charter
> >http://www.oasis-open.org/committees/regrep/charter.php and how
> >functionality we add affects our interoperability as well as the
> >requirements for core components, BP, CPPA, etc.  There are areas of
> >overlap it is true: an ebXML Registry manages metadata about the
> >registered objects, and a CMS manages metadata as well.  However, an
> >ebXML Registry has a larger and slightly different scope and as such it
> >can support and enable content management, but is not a standard
> >developed specifically for CMS.
> >
> >Kathryn
> >
> >-----Original Message-----
> >From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM]
> >Sent: Thursday, December 18, 2003 12:34 PM
> >To: Collins, Jeff
> >Cc: ebXML Regrep (ebXML Regrep)
> >Subject: [regrep] ebXML Registry and Content Management (was Re:
> >[regrep] Meeting agenda and reminder for ebXML Registry telecon December
> >18th, 2003)
> >
> >
> >Collins, Jeff wrote:
> >
> >
> >
> >>Ok, so i guess i'll follow up with a few more questions:
> >>
> >>- What industry vendors have agreed to support this spec so far?
> >>
> >>
> >>
> >I assume by "support" you mean implementors of the ebXML registry (as
> >opposed to users of ebXML registry)?
> >Until recently I used to say that ebXML Registry spec is weak on vendor
> >adoption and strong on end-user adoption.
> >This changed last month when Adobe acquired Yellow Dragon Software to
> >leverage their ebXML Registry within their eForms products. Peter, Duane
> >
> >and Matt represent Adobe on our TC and can give more details.
> >
> >Sun has an implementation in open source (see my signature).
> >
> >In addition there are several other implementations listed on our TC
> >page:
> >
> >http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
> >
> >Finally, there are those that we keep discovering. At XML 2003 I
> >discovered that the
> >Australian company MSI ( http://www.msi.com.au ) had an ebXMl Registry
> >implementation.
> >
> >But where we are doing even better is in actual end-user adoption and
> >deployment. Again see the first link in my signature for a small
> >example.
> >
> >
> >
> >>- Has there been any consideration of Portal Server integration use
> >>cases with the CM API?
> >>
> >>
> >>
> >As you know Portals and CM have a close relationship with portals being
> >the front end and ECM systems being the backend.
> >
> >Naturally, I see a close relationship between WSRP as a portal standard
> >and ebXML Registry as CM standard.
> >Recognizing that, we have recently formed a liaison with WSRP TC where
> >Joe Chiusano and I work in the Publish/Bind/Discover SC under Alan Kropp
> >
> >of Vignette. Based on initial discussion we feel that ebXMl Registry
> >brings a strong value to WSRP and portals.
> >
> >
> >
> >>- What would a CM vendor use ebXML for today if it doesn't support
> >>versioning as defined by the CM products on the market today?  Would it
> >>
> >>
> >
> >
> >
> >>be read only?
> >>
> >>
> >>
> >ebXML Registry supports tracking of versions today. It allows for
> >implementation specific extensions to support the missing check
> >in/checkout type functions. Until we support full versioning this aspect
> >
> >of CM would not be interoperable. Some interop is better than none in
> >the interim.
> >
> >
> >
> >>- How does ebXML interoperate with WebDAV?
> >>
> >>
> >>
> >ebXML Registry defines an abstract API in UML and then defines normative
> >
> >bindings to SOAP, HTML and ebXML Messaging. a binding to WebDav has not
> >been defined yet. If we see a demand for it we could consider it.
> >
> >
> >
> >>Overall, are there plans for reference ECM applications?
> >>
> >>
> >>
> >The reference application is the one that was defined in the ebXML
> >Architecture as an eBusiness artifacts registry for CPP/A, BPSS and CC.
> >Another reference application is Web Service publish/discovery. These
> >applications are deployed at Sun and other places. I would love to see a
> >
> >WSRP publish/bind/discover use case as a reference application.
> >
> >The killer application for ebXML Registry in my opinion is eForms.
> >
> >
> >
> >>Plans for application support or integration from Portal Vendors or
> >>Apache in something like Cocoon?
> >>
> >>
> >>
> >The freebXML Registry project under freebxml.org is where a grassroots
> >group of vendor and user companies are working together on ebXML
> >Registry.
> >
> >
> >
> >>How would a vendor achieve benefit from committing resources to this
> >>specification?
> >>
> >>
> >>
> >>
> >Like any other standards work, a vendor should only get involved if they
> >
> >feel the standard is important to their future. By getting involved they
> >
> >make sure that their customer/product needs are met within the standard
> >and that they are not stuck with a lot of baggage that they do not wish
> >to implement in their products.
> >
> >
> >
>
> -- 
> Senior Standards Strategist
> Adobe Systems, Inc.
> http://www.adobe.com
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
>
>