RE: ebXML glossary

[Stuart Campbell <stuart.campbell@tieglobal.com>]

Mary Kay

 

A belated quick answer to your question - just after the *.  I think the issue isnt so much with CC but BP although i confess to not having read those specs in so much details

 

• §         ebXML Business Process specification schema *true it gives the option of uml or schema (but still...)
• §         ebXML Methodology for the Discovery and Analysis of Core Components * neutral
• §         ebXML Naming conventions for Core Components and Business Processes  * neutral
• §         ebXML The role of context in the re-usability of Core Components and Business Processes *99.9% ok, but would like to see xml sample listed as an example
• §         ebXML Specification for the application of XML based assembly and context rules * non neutral - eg DTD maintenance thus non EWG+ 

However, i also feel that at the moment the CC/BP area is still a little lacking on the 'yes, but what do i do now' aspect of ebXML.  If i think what my company may be doing with these point there are some areas missing/next phases and my belief a lot of these will be related to the registry/repository to real make ebXML glide along.  If this would be so,  then my argument, imho, becomes stronger.

 

 

Regards

 

 

STUART

-----Original Message-----
From: Blantz, Mary Kay [mailto:mblantz@netfish.com]
Sent: Tuesday, February 27, 2001 20:34
To: 'stuart.campbell@tieglobal.com'; Blantz, Mary Kay; 'agrangard@nycall.com'; 'Lynne Rosenthal'; 'ebXML-Architecture List'
Subject: RE: ebXML glossary

Hi Stuart,

 

If your time permits, could you expand on the comment about 'several of the deliverables'?  I don't

disagree, I just don't understand.

 

Thanks,

MK

-----Original Message-----
From: Stuart Campbell [mailto:stuart.campbell@tieglobal.com]
Sent: Tuesday, February 27, 2001 11:32 AM
To: 'Blantz, Mary Kay'; 'agrangard@nycall.com'; 'Lynne Rosenthal'; 'ebXML-Architecture List'
Subject: RE: ebXML glossary

Mary

 

I agree fully with your statement - any syntax neutral CC/BP activites i think can fit nicely into EWG+.  However, looking at several of the deliverables they are not syntax neutral and XML seems to serve more than an example.  If this is true, such cases need to be demerged and then split along the lines i suggested. 

 

Stuart

-----Original Message-----
From: Blantz, Mary Kay [mailto:mblantz@netfish.com]
Sent: Tuesday, February 27, 2001 14:42
To: 'stuart.campbell@tieglobal.com'; 'agrangard@nycall.com'; 'Lynne Rosenthal'; 'ebXML-Architecture List'
Subject: RE: ebXML glossary

Hi Stuart,

 

I'm not sure I understand why EWG+ (good term!) wouldn't be responsible for the BP/CC

specifications themselves.  If by EWG+ you mean some group under UN/CEFACT, I think

that's precisely where the business-related work belongs.  And since we on BP/CC are

working towards genuine 'syntax neutrality' it seems to make sense that the development

of standards, whether XML or X12 or EDIFACT or YAML, be done in the same place, at

the same time, by the same experts.  The groups may not be as technical adept at XML

as they might want to be, but I'm sure that the appropriate technical people would be

willing to work with us.

 

Mary Kay

-----Original Message-----
From: Stuart Campbell [mailto:stuart.campbell@tieglobal.com]
Sent: Tuesday, February 27, 2001 6:23 AM
To: 'agrangard@nycall.com'; 'Lynne Rosenthal'; 'ebXML-Architecture List'
Subject: RE: ebXML glossary

Re - Definition of 'Infrastructure' correspondence

 

This raises an important question...there appear to be two basic sides to the output of ebXML. 

- BP/CC activities - so called content

- Non BP/CC - what most call infrastructure (even if the glossary doesnt)

 

However, my belief is that it is not this sort of split (CC/BP vs non CC/BP) which is important.  The split which i believe is important is:

 

- Specifications for the whole of ebXML

- Content which is built by using the specifications (in reality this means BP (process catalogues) and CC (Core component catalogues))

 

The difference with the top view is that BP/CC activities also contain specifications and the development of these specifications are interlinked with other ebXML specifications and it would be illogical to split the two up.  Splitting away the content is far easier to boundary.

 

Thus, in conjunction with the 'where next' discussion...this logic would suggest that all specifications, guidance material etc would logically go to OASIS, and the content/catalogues which related to these specifications is performed by EWG+.  The main difference is that the EWG would not be responsible for BP/CC specifications themselves.

 

 

Regards

 

 

STUART


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Campbell
Technical Strategy Director, TIE Holding NV
UK Office    T:+44 1270 254019   F:+44 7971 121013
Netherlands  T:+31 20 658 9335   F:+31 20 658 9901
Global       M:+44 7970 429251   E:stuart.campbell@TIEGlobal.com
                 W:www.TIEglobal.com P:www.stuartcampbell.co.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

 

 -----Original Message-----
From: agrangard@nycall.com [mailto:anders.grangard@edifrance.org]
Sent: Monday, February 26, 2001 14:27
To: Lynne Rosenthal; ebXML-Architecture List
Subject: Re: ebXML glossary

The term ebXML Infrastructure has been used with different meanings within ebXML. We decided in Vancouver to stick with the interpretation of the TA specification, i.e. meaning the entire framework. If we feel we need to distinguish between the BOV and FSV views, we should either use these terms or come up with new ones.

 

Anders

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

From: Lynne Rosenthal

To: ebXML-Architecture List

Sent: Thursday, February 22, 2001 1:29 PM

Subject: Re: ebXML glossary

It probably should be noted, that the definition for ebXML Infrastructure is not consistent with the way it was used during  the Thursday meeting (in Vancouver) regarding the future of ebXML.  At that meeting, Infrastructure was used to indicate those ebXML specifications that would probably go under OASIS - that is, Reg/Rep, TRP, and Trading Partners.   The current glossary definition states that the Infrastructure is ALL the specifications.

Lynne


At 01:04 PM 2/22/01 +0100, agrangard@nycall.com wrote:

Content-type: text/plain
X-MIME-Autoconverted: from 8bit to quoted-printable by ridley.nist.gov id f1MCE8B02801

Attached you will find the updated ebXML glossary to be voted at the next
steering committee conference call.


Anders Grangard
Edifrance
Ingénieur - Consultant en Commerce électronique
Tel: +33 (0)1 42 91 62 24
http://www.edifrance.org