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
>
Powered by
eList eXpress LLC