RE: latest Version

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Scott,

	of course the opinions expressed in my comments are MINE and do not reflect Sun's position!

Now, on the content:

1.	RegRep.
	I apologize for my english. What I meant is that, of course the RegRep can 
	store anything, but for most of the items the reference representation is 
	the one in XML.

2.	UML
	I agree on the value of UML, of course. I do not know if the XML viewpoint 
	is in the FSV, I do not enter in the this context.
	It is clear that SMEs will not look inside the XML documents to 
	understand which BP to use. I would think that they will rather look
	at the textual representation.
	What I meant was that the use of ebXML should be presented, as you say, as
	a valuable help to formalize the information in a neutral way but should
	not be described as a necessary step.

3.	Open-EDI.
	My position is the following. Simplify the text, present the basic concepts
	"as if" they are ebXML concepts and simply reference Open-EDI in the
	literature with a footnote.
	I think that "introducing the Open-EDI", as it is in the book, distracts the
	reader from the main thread. What is the goal of the section? Introducing FSV
	and BOV, I think. Should we call them FSV and BOV? If yes, let's call them
	that way and footnote that these concepts were first discovered in the
	Open-EDI. The real important thing is to try to explain why FSV and BOV
	are important, not to track their origins.

Best regards

/Stefano

> -----Original Message-----
> From: Nieman, Scott [mailto:Scott.Nieman@NorstanConsulting.com]
> Sent: Tuesday, October 17, 2000 12:53 AM
> To: 'stefano.pogliani@sun.com'; ebXML Architecture
> Subject: RE: latest Version
> 
> 
> >>The RegRep only knows about the things in the XML format.
> 
> Where is this coming from?  reg-rep can store ANYTHING as long as it is
> classified.  We call them "objects" for that very reason and for lack of a
> better term.  An registered object can be classified in a way that actors
> will know it is in XML syntax.  the classification scheme ITSELF is a
> registered object.
> 
> >> I disagree with the use of UML in this context, which seems to be
> prescriptive for the use of ebXML.
> 
> Is this a Sun position statement?  Or a Stefano position statement?  It is
> NOT AT ALL prescriptive for the SME (ONE of the ebXML customers), 
> but it is
> simply a GOOD IDEA to keep the business process information in a protocol
> and technology neutral viewpoint.  XML is not a neutral viewpoint, but
> completely in the FSV.   I feel the architecture document does a 
> good job in
> showing how in concept a model can be recast into XML syntax. 
> 
> To think a mom and pop shop (small company, say 4-5 people) will spend one
> minute describing their business process in ANY TOOL is a joke...they are
> more likely to spend time finding one from a LIST that CLOSELY 
> MATCHES their
> process and using it.   How it got into that list is likely 
> through software
> companies, standards organizations, industry groups and so forth, and this
> is where the UML comes into play.  All the SME wants is to see the process
> as a simple visual flowchart (e.g.; UML Activity diagram), which to me is
> only a matter of rendering.  Put an XML schema in front of them and their
> eyes will glaze over.  
> 
> >>By reading this, one would understand that ebXML is to continue the
> open-EDI effort or, worst, to make it finally succesful >>!  I mean, if
> ideas from Open-EDI can be reused, they should be presented "as 
> ebXML ideas"
> and, then, a footnote would 
> >>reference the literature on open-EDI just as a referenced source.
> 
> Worst? My philosophy on technology is that whatever is "new" is actually
> "old" (or an adaptation of "old").  Open-edi concepts are over 10 
> years old,
> and are based on ONE main issue:  why is it so hard to implement EDI??
> Technologists and the business people ALWAYS have had a 
> disconnect from the
> business requirements and actual implementation.  Modeling is 
> viewed as the
> way to bridge this gap.  Open-edi was ALWAYS about auto-discovery and
> auto-configuration of trading partners, and most importantly ensuring a
> future-proof way to represent and understand a business model.  
> To eliminate
> Open-edi as an origin of the architecture is a big mistake.  But 
> to simplify
> the text, I am all for it.  
> 
> btw, I hope we don't have to ask the same question again 10 years 
> from now;
> why is it so hard to implement ebXML??  Just think, ten years 
> from now we'll
> all be talking/debating about the "new technology craze" as big as XML is
> today. I just hope that we won't be debating these SAME business modeling
> issues again.  I hope we can someday get beyond this discussion.
> 
> Lots of hope for ebXML,
> 
> Scott Nieman
> Solutions Director/ e-Business Integration
> Norstan Consulting
> 
>   
> 
>