OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Party XML Schema Defintions


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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC