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

Matt,

 

All you are telling me is where OASIS succeeds with 
its TC process.

 

The individual TCs have, and are providing the 
technical implementation

level that CEFACT cannot.

 

And today the individual TCs are continuing to do 
that job.  

Those TCs also are liaising together about 
technical issues and

enhancements.

 

That's why I moved 
the OASIS CAM work out of CEFACT into OASIS,

and similarly strongly supported the move of BPSS 
too.

 

Now it would make sense for the Registry to say to 
the other

ebXML TCs - we're releasing V3.0 - and here's a 
laundry list

of things we'd like you to make sure interoperate 
between

us - and new features we're adding - and it would also make 

sense for OASIS itself to decide to launch a V3.0 of ebXML 

and then have the TCs interact to make that all happen.

 

I think we're both saying we have enough big 
picture 

already - what we need is use cases that illustrate 
the 

benefits and applicability - and that is definately 
what

I'm after getting to.

 

I'm just not so sure we want a separate group 
telling each TC 

what they need to be 
doing instead here.

 

Cheers, DW.

  
----- Original Message ----- 

  
From: 
  Matthew MacKenzie 
  

  
To: David RR Webber 

  
Cc: Breininger, Kathryn R ; Collins, 
  Jeff ; Duane 
  Nickull ; Farrukh Najmi ; ebXML Regrep (ebXML Regrep) 
  

  
Sent: Sunday, December 21, 2003 2:19 
  PM

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

  

David,

Where I work, Architecture is pretty concrete. 
  Developers actually implement the architecture that is given to them, and if 
  the architecture is not implementable, the architects have to fix it before 
  implementation can start. All this means in the ebXML context is that our 
  quality level has to be higher than the CEFACT process permitted/supported. 
  

The CEFACT idea of Architecture was in line with CEFACT's overall 
  approach -- Top Down from Confused User's Perspective (TD-CUP). In my view, 
  that sort of top down focus should end at the requirements gathering phase, 
  then the technical architects go to work. This parallels successful 
  professional software development patterns:

user->product 
  management->architect->implementer->user

CEFACT promoted an 
  architecture that was driven by the consumer, and unfortunately the 
  architecture was only consumable by the consumer and not the implementer. This 
  is a failing of the CEFACT process and orientation, not of the architecture 
  concept.

-Matt

On 20-Dec-03, at 3:34 PM, David RR Webber 
  wrote:

  Matt,
 
I 
    think we are seeing the same thing here - much more real world - centric.
 
I'm 
    not sure the word "Architecture" in the title sends the right message.
People 
    are overdosed on all that - theory side - stuff - what we need is
healthy 
    pragmatism and showing what can be built and 
    works.
 
Something 
    like "ebXML Solution Configuration" would be my preference.
 
DW.
 
p.s. French 
    perhaps - "Solution et XML avec ebXML (SEXAE) - sorry, 
I have no 
    idea what came over me then!?!  Too much architecture is
clearly 
    not good for you...
 
----- 
    Original Message -----
From: 
Matthew 
    MacKenzie 
To: 
David RR 
Webber 
Cc: 
Breininger, 
    Kathryn R; Collins, Jeff ;Duane Nickull ;Farrukh Najmi ;ebXML Regrep 
    (ebXML Regrep) 
Sent:Saturday, 
    December 20, 2003 9:16 AM
Subject:Re: 
    [regrep] ebXML Registry and Content Management (was Re: [regrep] Meeting 
    agenda and reminder for ebXML Registry telecon December 18th, 2003)

David,

I think an ebXML 
    Architecture could be useful if its goal is to define best practices, 
    deployment patterns and general guidance for technical committees. It would 
    be quite helpful if an architecture group could maintain the high level view 
    of our ecosystem, so that interoperability between specifications remains a 
    key goal. United we stand, divided we fall, 
    right?

-Matt

On Dec 19, 2003, at 9:58 PM, David RR Webber 
    wrote:

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" 
    <>
To: "Breininger, Kathryn R" 
    <>
Cc: "Farrukh Najmi" 
    <>; "Collins, 
    Jeff"
<>; "ebXML Regrep (ebXML 
    Regrep)"
<>
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:]
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.

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.

___________________________
Matthew 
    MacKenzie
Senior Architect
Intelligent Documents Business 
    Unit
Adobe Systems Canada Inc.
http://www.adobe.com/
506 
    869.0175