Re: CC minutes

["agrangard@nycall.com" <anders.grangard@edifrance.org>]

Title: RE: CC minutes

All of these issues are paramount to ebXML but given that the deadlines already were passed, I did not see how they could be incorporated into this version and get a team consensus. HOWEVER - now to the good news. At the steering committee this evening (or morning if you are in the US) Klaus presented a revised time plan on behalf of the project management team, which got approved. The deadline for submission to the second review cycle for a Vancouver approval is now 10 January, after which we have two weeks to deal with the comments and a team approved final version.

 

I will send you an updated work plan tomorrow but I suggest that we vote the specification at our next conference call the fourth January.

 

Anders

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

From: Brian Eisenberg

To: 'agrangard@nycall.com' ; Christopher Ferris ; ebxml-architecture@lists.ebxml.org

Sent: Wednesday, December 20, 2000 1:30 AM

Subject: RE: CC minutes

Anders - I disagree. The capitalisation and conformance issues were mandated by the QR team in Tokyo. Furthermore, Klaus informed us that we need to at least have a short section on security in the spec. I believe Duane has addressed the security issue. At this time, we will continue with our internal team review of the spec and will incorporate the team comments and other outstanding items before the document is submitted to the plenary for approval in Vancouver.

--Brian

-----Original Message-----
From: agrangard@nycall.com [mailto:anders.grangard@edifrance.org]
Sent: Friday, December 15, 2000 2:50 PM
To: Christopher Ferris; ebxml-architecture@lists.ebxml.org
Subject: Re: CC minutes

Chris/Team

The capitalisation issue deserves more attention than what is possible
before the TA spec has to be circulated. I suggest that we treat this as a
technical attachment for possible inlusion later, as we are doing with the
conformance and security issues. As with these two examples they are a must
but does not make or brake the technical architecture.

Good night
Anders

----- Original Message -----
From: Christopher Ferris <chris.ferris@east.sun.com>
To: <ebxml-architecture@lists.ebxml.org>
Sent: Friday, December 15, 2000 7:29 PM
Subject: Re: CC minutes

> Hmmm...
>
> This may not fit into any of the currently identified
> sections.
>
> It would be closest to Design Objectives I guess. Possibly
> a new sub-section which was entitled: "Design Conventions for ebXML
Specifications"
> or something to that effect.
>
> Cheers,
>
> Chris
>
> > Brian Eisenberg wrote:
> >
> > Sorry about that :-)
> >
> > Section 4.5 refers to conventions for the TA document, not ebXML.
Perhaps we could insert a
> > "Naming Conventions" or "Capitalization" sub-section (5.3
Capitalizatoin) in the design objectives
> > section (5)
> >
> > Thoughts?
> >
> > EBXML TECHNICAL ARCHITECTURE SPECIFICATION      1
> > 1 STATUS OF THIS DOCUMENT       1
> > 2 EBXML TECHNICAL ARCHITECTURE PARTICIPANTS     1
> > 4 INTRODUCTION  3
> > 4.1 Summary of Contents of Document     3
> > 4.2 Audience and Scope  4
> > 4.3 Related Documents   5
> > 4.4 Normative References        5
> > 4.5 Document Conventions        5
> > 5 DESIGN OBJECTIVES     5
> > 5.1 Problem Description and Goals       5
> > 5.2 Caveats and Assumptions     6
> > 6 EBXML SYSTEM OVERVIEW 6
> > 7 EBXML ARCHITECTURE REFERENCE MODEL    8
> > 7.1 Overview    8
> > 7.2 ebXML Business Operational View     10
> > 7.3 ebXML Functional Service View       12
> > 8 EBXML FUNCTIONAL PHASES       13
> > 8.1 Overview    13
> > 8.1.1 The Implementation Phase  13
> > 8.1.2 The Discovery and Retrieval Phase 13
> > 8.1.3 The Run Time Phase        13
> > 8.2 Implementation Phase        14
> > 8.3 Discovery and Retrieval Phase       14
> > 8.4 Run Time Phase      15
> > 9 EBXML INFRASTRUCTURE  15
> > 9.1 Trading Partner Information [CPP and CPA's] 15
> > 9.1.1 Introduction      16
> > 9.1.2 CPP Formal Functionality  16
> > 9.1.3 CPA Formal Functionality  16
> > 9.1.4 CPP Interfaces    17
> > 9.1.5 CPA Interfaces    17
> > 9.1.6 Non-Normative Implementation Details [CPP and CPA's]      17
> > 9.2 Business Process and Information Modeling   18
> > 9.2.1 Introduction      18
> > 9.2.2 Formal Functionality      18
> > 9.2.3 Interfaces        19
> > 9.2.4 Non-Normative Implementation Details      19
> > 9.3 Core Components and Library Functionality   20
> > 9.3.1 Introduction      20
> > 9.3.2 Formal Functionality      20
> > 9.3.3 Interfaces        21
> > 9.3.4 Non-Normative Implementation Details      21
> > 9.4 Registry Functionality      22
> > 9.4.1 Introduction      22
> > 9.4.2 Formal Functionality      22
> > 9.4.3 Interfaces        23
> > 9.4.4 Non-Normative Implementation Details      24
> > 9.5 Messaging Service Functionality     24
> > 9.5.1 Introduction      24
> > 9.5.2 Formal Functionality      27
> > 9.5.3 Interfaces        27
> > 9.5.4 Non-Normative Implementation Details      28
> > 10 CONFORMANCE  29
> > 10.1 Introduction       29
> > 10.2 Conformance to ebXML       29
> > 10.3 Conformance to the Technical Architecture Specification    30
> > 10.4 General Framework of Conformance Testing   30
> > APPENDIX A: EXAMPLE EBXML BUSINESS SCENARIOS    31
> > Scenario 1      31
> > Two Trading Partners set-up an agreement and run the associated
exchange.       31
> > Scenario 2:     32
> > Three or more Trading Partners set-up a Business Process implementing a
supply-chain eBusiness
> > scenario.        32
> > Scenario 3      34
> > A Company sets up a Portal which defines a Business Process involving
the use of external business
> > services     34
> > Scenario 4      34
> > Three or more Trading Partners engage in eBusiness using Business
Processes that were created by
> > each respective Trading Partner and run the associated business
exchanges.     34
> >
> > DISCLAIMER      36
> > COPYRIGHT STATEMENT     36
> >
> > -----Original Message-----
> > From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> > Sent: Friday, December 15, 2000 10:18 AM
> > To: Brian Eisenberg
> > Cc: agrangard@nycall.com; ebxml-architecture@lists.ebxml.org
> > Subject: Re: CC minutes
> >
> > Brian,
> >
> > the snippet should probably come from Nikola's draft
> > recommendation, not my rambling.
> >
> > As for which section, since I cannot read the TOC
> > (no Word for Solaris last time I checked;-) I'll
> > leave that decision up to you folk.
> >
> > If I recall earlier versions, wasn't there a conventions
> > section or something to that effect?
> >
> > I would not place it in the compliance section, that's
> > something completely different.
> >
> > Cheers,
> >
> > Chris
> >
> > > Brian Eisenberg wrote:
> > >
> > > I absolutely agree with Chris, and propose that I insert his wording
into the TA spec (which I'm
> >
> > > putting the finishing touches on this morning. I'll have it out to the
group by the end of the
> > day
> > > (Seattle time).
> > >
> > > Chris - any suggestion on what section of the document would be the
best place to insert this
> > > snippet?
> > >
> > > Please find the attached TOC for the latest TA spec.
> > >
> > > --Brian
> > >
> > > -----Original Message-----
> > > From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> > > Sent: Friday, December 15, 2000 9:35 AM
> > > To: agrangard@nycall.com
> > > Cc: ebxml-architecture@lists.ebxml.org
> > > Subject: Re: CC minutes
> > >
> > > Anders/team,
> > >
> > > With regards to:
> > >
> > > "Nicola reported that only one response had been received on his email
on the subject, which
> > > should
> > > be called Capitalisation rather than naming convention to avoid
confusion with the work being
> > > performed by the Core Components team on the semantic aspects.
> > >
> > > It was agreed that this should remain a task for the Technical
Architecture but close
> > cooperation
> > > with the other teams is needed."
> > >
> > > Why does this never seem to get resolved and finalized? There has been
some
> > > discussion around this for as long as I can recall. We (TR&P and TP
teams)
> > > need to have the issue resolved once and for all.
> > >
> > > I am in favor of the proposal (UpperCamelCase for Elements,
lowerCamelCase
> > > for attributes), but without clear guidance, we're likely to end up
with
> > > a bunch of DTD or XSD schemas which have differing capitalization
schemes
> > > which is (IMHO) unprofessional and would reflect poorly.
> > >
> > > PLEASE make a CLEAR and UNAMBIGUOUS decision on this matter and do so
> > > quickly. We are trying to finalize these various DTD/XSD schemas that
the
> > > infrastructure components define/require.
> > >
> > > Thanks,
> > >
> > > Chris
> > >
> > > "agrangard@nycall.com" wrote:
> > > >
> > > > Please find attached the minutes from yesterday's TA conference
call.
> > > >
> > > > regards
> > > >
> > > > Anders Grangard
> > > > Edifrance
> > > > Ingénieur - Consultant en Commerce électronique
> > > > Tel: +33 (0)1 42 91 62 24
> > > > http://www.edifrance.org
> > > >
> > > >
> > >
>
> --------------------------------------------------------------------------
--------------------------
> >
> > >
> > > >                        Name: TA_CC_141200.doc
> > > >    TA_CC_141200.doc    Type: Microsoft Word Document
(application/msword)
> > > >                    Encoding: BASE64
> > >
> > >
> > >
> > >                  Name: TA TOC.doc
> > >    TA TOC.doc    Type: Microsoft Word Document (application/msword)
> > >              Encoding: base64
>