RE: Party XML Schema Defintions

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

Martin,
	please find my comments embedded in your text.
Regards
/stefano

» -----Original Message-----
» From: Martin Bryan [mailto:mtbryan@sgml.u-net.com]
» Sent: 06 February 2001 09:12
» To: Stefano POGLIANI
» Cc: ebxml-core@lists.ebxml.org; james.whittle@e-centre.org.uk
» Subject: Re: Party XML Schema Defintions
»
»
» >If an SME simply has a small application using FoxPro or Access, it has
an
» application (legacy) that is currently used. I do not think that it will
be
» viable to avoid to link such application with the possibility of running
» ebXML Conversations. SME would not enter twice the same PO !
»
» Exactly. If an SML already has a small application using Access why the
hell
» should he be forced to create ebXML BP, BOV, FSV, CPP, TPa, UTCAA,....
» formal definitions of his processes.

	Just to "link" their internal legacies with the external collaborations.
	Nobody forces them to use ebXML. ebXML is an advantage they may acquire
	to make more consistent and homogeneous the dealing with external
	partners.

	If they were already having exchanges with those partners, most likely
	these exchanges were based on manual activity which was disconnected
	from the internal operations with the legacies. ebXML would allow them
	to integrate the two worlds under the agreement mentioned by the CPA
	and described by the BP they decided to support.

	If they were not having exchanges yet, ebXML would be the way for them
	to start doing these exchanges.

»
» >Also, there is the "problem" of the Business Process (and of the CPA). In
a
» first approximation, the ebXML software could simply deal with the
» sending/receving of XML documents; but, I think, it will be also required
to
» have some software which manages the conversation, i.e. helps the SME to
» executing the Business Process that has been agreed with the other party.
»
» That software should not be specific to just this process. It should be an
» application of a general-purpose tool which is likely to already be in the
» possession of the SME, e.g. a web browser with XSLT capabilities.

	The software may have a core part that is independent of the BP. But,
	in order to properly link the two worlds (as I mentioned before) it will
	be likely that a part of that software will depend on the actual way
	in which it is linked to the legacy world.
	Finally, not all BPs are equal. So, whilst it may be possible/envisageable
	to have part of the core software to be able to execute different
	instances of a BP, this would be another "variable part".


»
» >Leaving the process management completely to human activity would not be
of
» great help. (Here I am not saying that the process MUST ALWAYS be
automated
» and no human intervention is required. But that a support for ensuring
that
» the Business Process is run accordingly to the CPA is something that users
» will need).
»
» Automating processes that occur only one or two times a week is not
» cost-effective.

	Depends on how much would it cost to do this.
	SMEs would anyway requrire to grab some software that would be able to
	perform TRP. If they could, at the same time, grab the other part of
	the software that could link to the legacy, it wouldn't be so bad,
	I think.

»
» >In this context, even if I do not have an already existing application to
» interface with ebXML, I think that a solution composed by XML/XSLT would
be
» viable only if the BP is very trivial (I do not think that XSLT could be
» used also for that).
»
» Most SMEs have very trivial BPs. Most of them do not even have formal
» procedures but work on an ad-hoc basis. My point is that if we want to
» attract more than a few percent of the larger SMEs we have to be able to
» work using extremely simple, probably manually controlled, procedures that
» do not need more than a few seconds to set up.

	Agreed on the principle of "easy and quick set up". I do not think,
	though, that XSLT alone would be able to accomplish such a task.
»
» Martin Bryan
»
»