Re: FWD: re: POC liaison report

[Nicholas Kassem <Nick.Kassem@eng.sun.com>]

At 09:48 PM 8/3/2000 -0400, David RR Webber wrote:
>Message text written by Klaus-Dieter Naujok
> >
>In regard to RosettaNet, it is payload only, the same way we used
>OTA in Brussels.  Reason being, we don't have a ebXML payload yet
>:-(
><<<<<<<<<<<
>
>Klaus,
>
>Please - then lets concentrate on creating such a payload,
>and yes, that is one item GUIDE focuses on, and yes we have lots
>of other XML based payloads that we can use too.

What would you have preferred to see and which vendor was willing to sign 
up to show this "payload". Point them to me. I'll work with them.


>We don't need to depend on RosettaNet, and we certainly don't need a POC
>document that mentions 'RosettaNet Demo' as the title - instead of
>'ebXML Demo - ( payload - RosettaNet PIP3A transaction)'.

I'll have the title changed. No big deal.


>Minor details perhaps, but some may note this speaks volumes here
>to the mindset.

Perhaps.


>I presume the use of vendor and vendor product names is something
>else that we will not see endorsed?  A participants list seems more
>than adequate as in the past practice with all other ebXML documents.

I am not aware of any product names showing up in any press releases coming 
out of ebXML.org. If you are aware of this I'll work to fix it.


>(i.e. A configuration diagram should contain names such as 'delivery
>server',
>'ebXML enabled server', 'trading partner A', and so forth).
>
>A configuration diagram should also contain how it fits into the overall
>ebXML architecture as in the latest release of the ebXML Architecture
>document, and refer back to that document where applicable.

Great. Help us craft this - I'll include it in the handouts.


>Some people may infer from this that I am anti-RosettaNet.   Actually
>I'm currently involved in implementing a RosettaNet PIP and interchange
>mechanisms.
>
>Therefore, while participation from RosettaNet is welcome, we have
>to be careful to distinguish between rational decisions based on
>sound technical engineering that leads to long term mature
>standards, and short term convenience based on commercial
>expedience.

Agreed but I'm still stuck on what a dynamic CC means and where it fits ? I 
may be slow but I'm willing to learn.


>And we all know who usually loses, and who ends up picking up
>the costs over the years.

Amen. I'm all for getting it right and this won't happen unless you get 
serious developers in the loop. I wrote an ASN.1 compiler in my youth based 
on the CCITT red book specifications for a ISO/OSI Presentation/Rose layer. 
Guess how useful that turned out to be ?

Nick