[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] ebXML Registry and Content Management (was Re: [regrep]Meeting agenda and reminder for ebXML Registry telecon December 18th, 2003)
+1 Zachary. Couldn't agree more. Matthew MacKenzie Senior Architect, IDBU Adobe Systems matt@adobe.com On 20-Dec-03, at 10:34 PM, Zachary Alexander wrote: > Duane, > > If the ebXML Architecture team is reconstituted, count me in. I know > what it's like to start an architecture development effort when the > standard group that owns the spec doesn't either create a reference > architecture description or doesn't maintain it. I have used > Architecture Analysis to maintain transparency in the decision making > process which leads to better governance in the IT Acquisition process. > I've killed a lot of expensive and/or bad projects after doing the > architecture analysis. > > As an industry, we are getting killed because of cost over runs due to > poor planning and undifferentiated me-to-products. Anecdote: Poor up > front planning can routinely result in 40-80% cost over runs. > > > Zachary Alexander > The IT Investment Architect > ebTDesign LLC, (703) 283-4325 > http://www.ebTDesign.com > http://www.p2peconomy.com > http://www.itinvestmentvehicle.com > > > > > -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Friday, December 19, 2003 6:27 PM > To: Breininger, Kathryn R > Cc: Farrukh Najmi; Collins, Jeff; ebXML Regrep (ebXML Regrep) > 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_workgr > oup.php. > > > > 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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]