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