RE: ebXML TA spec v1.0 - LAST CALL for public comments

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

Title: ebXML TA spec v1.0 - LAST CALL for public comments

Dear Brian

 

Please see below comments on the ebXML TA spec v1.0 which i have read with vigour and without any preconceived views.  They are divided into editorial (real low level stuff and non-editorial (clarification, open questions).  Certainly i saw no show stoppers except for security.

 

In general, i think the document is well written and in most areas fairly clear in the direction.  The one exception is the area on security which is in essence surprisingly missing (with a weak explanation why) and a few sections (e.g. 631) which are so abstract and full of new undefined terms they are rather difficult to grasp.

 

Having also re-read the requirements specification i do not see major conflicts although the requirements specification for ebXML as a whole should itself be.

 

Although there are many editorial comments, i would class many as 'lack of clarification'.  Most of these would be resolved with the inclusion of one or two example words (performed in some sections) since much terminology from many different areas is introduced.  It should be noted that a definition section would be useful but is currently missing and whilst i appreciate a global glossary is being developed, and is necessary, these documents are not on the table now.  I also think it very important you use the ebXML branding consistently (rather than EbXML, EBXML etc).

 

The perspective i have read this from at a personal level is someone who has taken a background interest in ebXML and now as a more proactive adopter and supporter.  From a TIE company perspective we are, of course, a well known supporter and committer to ebXML.   Thus I would see myself as a secondary audience in the definitions used in the specification, although i personally would have thought that this document is, or should, have people like my self  included in the primary audience.  Finally i should clarify that my colleague Colin Barnham from TIE is our main expert in this group and that my involvement is to read it more from a neutral and un-encumbered viewpoint.

 

I hope these comments are useful to you and your team (even if a little late).  I am at your disposal if you require any clarifications.

 

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

 

 

Non Editorial

6: The version number should be far clearer - rather hidden way in a file name.  Particularly on the first page and preferably on every page.  This also applies to the status of the document

148: Remove 'some' - automatically provokes thought 'whats hidden'

169-175  The source should be put on all of these - to identify how to get hold of them.  eg 169 and 175.  In particular i have no ideal where to even think about getting DC 128 GUID.

175 GUID - a label should be attached to give a hint what it is

254 This effectively says 'intoduces the following concepts and architecture:a standardized business messaging service.  At first view one can easily jump to the conclusion that this is a service 'run by ebXML' - i think it should be called a mechanism

260 This is perhaps more of a question.  From the diagram and text there is a very strong inference that implementation/profiles etc are always stored on a registry which is not held by a business.   From my understanding of discussions, as well as from a business viewpoint, i can well see registry implementations at company sites (which may or may link to the central repository network).  This has advantages and disadvantages of course.   I think this should be hinted at in the text/diagram and also the wider concept of a web of repositories rather than a single one since this is a first initial view of the architecture

373 There should be an additional sentence describing what are activity and sequence diagrams.  This would then be consistent with the text in eg 374 and 370 section (plus others)

390 Unless i missed something, in the diagram CPA/CPP are undefined and are not used or defined in the text immediately after the diagram.  These acronyms should be expanded since they have not yet been introduced

407-section  I think this is far too low level to be in an architecture specification.  If they are included it would be better to give a physical example rather than an abstract example

421 Dependent on your view of life this can imply that not only the specifications and ebXML infrastructure should be geared towards multilingualism, but also any thing you eg trade in ebXML or eg dump in the repository.  If the latter is taken then i as a user within one country (>90% of all traffic is national only) could infer that my 'content' should also be multilingually orientated.  I do not believe this would be of benefit

499 This implies 'minimum and no more'.  What i think it means as 'at a minimum but there may well be more'

531-534. I (and thus others) really do not understand the difference between 1 (trading partner could do) and 2 (trading partner is capable of doing).  If this 'distinction' is necessary it should be explained in more detail or the distinction and levels removed

576/578 I think this conflicts with 531/534 (or at least relationship is unclear) since it talks about the 'will' of cpa's is an abstract of 2 CPPs - ie is nothing else except for 'will'

589 Its says a CPA is negotiated after... this then conflicts with 531-534 which implies its more of a statement

587 section.  What has this paragraph got to do with non-normative.  I assume at first this was ebXML conformant payload vs user customized extension.  When i read the paragraph it talks about changing CPA (which is logical) but then also stops shorts at what should be done about them

617 nominal.  Does this mean MANDATORY

621 'standalone' implies to me 'no relationship between them' - is this true?

631 section.  This is fairly unintelligible.  There are a number of new terms introduced patters,signals etc some of which are undefined (eg signal) and are so abstract its hard to know what is meant.  It would be useful to put one or two examples in at this stage even if the more formal explanation comes later

642 The diagram of 642 should perhaps be enhanced to include signals and to show any relationship between the lower and upper items in the box (as far as i understand there must be some since they are in the same box).  Also put some text on the relationship lines to say what they mean.

670 Choreography is used (i think maybe even once before) but it is not really explained

682 I understand the statement but not the implication.  Is this related to external applications?

692 A 50 word sentence of terminology - help me understand this one - perhaps a diagram speaks a thousand words or at lest 50 :-)

701 It is un-obvious to me why this is 'MAY'

649 says shall be UML for business process modelling whereas 729 says may.  I guess this is because of the non-normative heading but i think it should be more explicit

738 Can core components be nested.  This paragraph suggests they cant

789 Can it be explained how the sentence relates to the heading of non-normative.  Whats does it really mean?

800 The diagram should be extended to show core components can be nested.  As it stands it suggests they can only be sequential

805 An example of a core component would be very informative at this stage

813 should be clear right at start that is a network of repositories - eg registries interface with other registries and users

835 what does 'information associations' mean?

835 what does 'mutability' mean????

838 what does 'file representation type mean' ???

847 Im pretty surprised that there is a MAY here.  For company repositories i could understand it but on the basis of a web of repositories which will invariably be needed for 'enabling a single global electronic market' i would have through these should all be mandatory.  In particular registry-registry interactions should be mandated for ebxml compliance

860 it suggests earlier that repository is not for human interactions - but in this sentence it suggests otherwise.  Am i missing something?

942 Maybe its addressed elsewhere/at a lower level but for messaging and repository services should there be a hint at the capability and response times expect by such systems.  In this document this should be hinted at to ensure it is addressed

1086 'vendor neutral organisation such as NIST and OASIS should'.  This is a) be a MAY, b) not push certain bodies especially since these both bodies are largely US and does not create a global picture c)There is no reason for conformance suites not to be generated by other organisations (including vendors)

1092 This section seems to be missing.  Its quite startling its not in the architecture specification. 

1250 If this scenario is so completely the same, why include it except widening the previous scenario

1250 I would like to see a scenario (which is different i think to scenario 4) where by there are three parties (no service provider) and where the transaction between two of them is totally dependant on the success of a transaction between the initiator and the third

 

 

 

Editorial

46:Klaus Naujoks name disappeared (may be true for others) between version 0.9 and this one!.  If he contributed then i assume he should still be in!

59, 61 vs 114.  A review thought the document should be made on the capitalisation of ebXML.  In many case it is EBXML which i believe is incorrect

138 There is no logical reason for MAY to be capitalised.  I know this is in RFC rules but does this really apply to narrative overview text as well as technical text.  Also in other sections

181: Is Bra97 needed - i automatically think 'what does this mean'

THROUGHOUT the document.  In consistent use of capitals/lower case in the bullets - eg cf 329-331 to 338-340

268-268 In essence this text is covered in 282 and is unnecessary, but at least it may be worth considering moving the 1st text

459 Shouldn't the arrows  from the registry to the libraries be two way

491 Remove the square bracket section in title - unnecessary

493-508 i think this section could be better phrased since its only when you get to 508/508 you really understand the relationship and then you wonder want the first part of the second paragraph means

510/527  Why is the word 'formal' needed - this implies there is also some informal functionality.  On 587 its says 'non-non normative' which i presume is supposed to be the opposite of formal.  It would be more logical to use either formal/informal or normative/non-normative

581 'Business Process document' - is this the right terminology since it hasnt been defined

584 for first stored say 'placed' so sentence reads better

619 what does 'other' mean

613 presumably 'design viewpoint'

744 ';go-together is superfluous

783 I dont this this makes sense.  How can a component interface with a element?

824 This statement is unnecessary.  It has already been defined at the start and is also lacking in other areas such or business process/core components etc

827 Should probably be a comma after 'granularity'

832 'are display' to 'would result in'

843 would be of benefit to add (presumably) 'this is not part of ebXML and would be through individual vendors'

909 Does this reference need to be more explicit in the list of references

925 This doesn't show any relationship, just a set of blocks

937 Should be explicit and insert VAN - this will be important to EDI users who often like the trust and reliability they give

1019 Should be 'specifies' and Should probably be 'section' not 'clause'

1019 The introduction to this section is nice and informative.  it would be of great benefit if it were adopted in other sections

1037 This is a real get out clause. You are either conformant to ebXML or not (even considering all the mays etc).  This should be tightened up and we should have confidence in our activities

1071 Extra space at start of bullet

:

-----Original Message-----
From: Brian Eisenberg [mailto:BrianE@DataChannel.com]
Sent: Friday, January 26, 2001 02:41
To: Brian Eisenberg; ''ebXML-Architecture List ' '
Cc: 'Klaus-Dieter Naujok (E-mail) '; 'Bob Sutor (E-mail) '
Subject: ebXML TA spec v1.0 - LAST CALL for public comments

All -

I just wanted to send a reminder out that the public comments period ends on Monday, January 29. After this deadline passes, Duane and I will dispose of the comments according to the process outlined in my earlier post [1]. Please distribute this last call accordingly.

[1] http://lists.ebxml.org/archives/ebxml-architecture/200101/msg00035.html

Regards,

--Brian

. . . . . . . . . . . . . . . . . . . . . . . .

Brian Eisenberg | Standards & Technology Liaison

600 108th Avenue NE | Suite 900 | Bellevue WA  98004
      T 425.467.2641 |  F 425.637.1192 | briane@datachannel.com

w w w . d a t a c h a n n e l . c o m