[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components...
Rachel, On Tuesday 23 April 2002 18:08, Rachel Foerster wrote: > James, > > Sounds interesting....except when I got to your statement: > > "- It enables this data to be seamlessly transferred between backend > systems or viewed and edited by users as required." > > How is this "seamless" transfer between backend systems accomplished. Who > has to set it up and what tools must they use to do so? If any one at the > SME site has to configure, then it misses my expectations. Octimal Forms produce Octimal Records. These records are generic in nature and are designed in such a way (at least when combined with RecordType information) that allows them to be exported to any datasource (using ODBC or unixODBC). The resulting tables are of course also generic and can be created on the fly by Octimal if required. Although Octimal does not require an ODBC datasource (it can simply use the filesystem), if one is available, then payload information can be exported to it in a generic fashion. This datasource may be as simple as an empty .mdb file (provided out of the box), or an existing relational database, in which the Octimal tables effectively act as holding/import tables. Through the use of various database objects (such as triggers), data stored in the generic Octimal holding tables can be synchronized with an existing schema, effectively by applying transformations at the database level. So, to conclude: 1. Octimal-lite can be downloaded free of charge and used without a database. 2. Those that wish to benefit from a database can begin do so simply by providing a DSN. 3. Octimal can also facilitate far more advanced integration if desired through the use of database objects. I hope this answers your questions. James -- James Wydenbach BitDaemons Ltd http://www.bitdaemons.com tel: +44 (0)1252 326402 > What I dream of is a backend system that does its normal functions plus all > you described. Is this a pipe dream or what? > > And shame on your for sleeping through all of this lively discussion here > in the colonies!!!! > > Rachel > > -----Original Message----- > From: James Wydenbach [mailto:firstname.lastname@example.org] > Sent: Tuesday, April 23, 2002 8:28 AM > To: Fred Blommestein, van; email@example.com; > firstname.lastname@example.org; email@example.com; > firstname.lastname@example.org > Cc: email@example.com > Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components... > > > Hello Rachel, Todd, Fred, Duane and everybody else, > > I've just picked this thread up (drawbacks of living in the UK and sleeping > when most of the interesting discussions are going on!). > > I thought I should draw your attention to the product which my company, > BitDaemons, is developing, called Octimal, which, it seems, addresses many > of > the points in this thread: > > - It is targetted at SME's > - It is an out-of-the-box, off-the-shelf solution > - A free, downloadable version will be released to SMEs > - It operates as a business-specific e-mail type system, offering the host > company complete control over all outbound and inbound messages and > residing on their internal systems. > - It enables the transfer of XML-based (including UBL) documents between > parties > - It enables this data to be seamlessly transferred between backend systems > or viewed and edited by users as required. > - The viewing and editing of the data takes place in a rich user interface > and the document can then be transferred to the company's backend data > store or published to a variety of other formats as is the company's > document policy. > - It is ebXML-compliant. > > We demonstrated this product at the European Software Vendor's conference > at eBES last month and, indeed, made the point that unless ebXML is widely > adopted by SMEs then it will struggle to achieve its goals. > > We believe Octimal will greatly benefit the take up of ebXML and are > looking for partners to help us bring it to market. > > Please forgive the plug, but as this thread has been discussing the need > for a product with all the features that Octimal offers, I thought I should > bring > it to your attention. > > Thanks, > > James > www.bitdaemons.com > > On Tuesday 23 April 2002 00:08, Fred Blommestein, van wrote: > > Rachel, > > > > You may differ with me, I don't with you. > > I also want it in a processable way AND in a viewable way. That's why XML > > was invented. I want the flexiblity at the receiver's side to set the > > level > > > of integration without bothering the sender. ebXML IMO doesn't support > > that > > > (yet). > > > > Fred > > > > <<< "Rachel Foerster" <firstname.lastname@example.org> 4/23 1:37a >>> > > Fred, > > > > This is where you and I differ....I want the data in a processable > > format. I don't want to look at it on my monitor. Until I can get it this > > way I'll continue with good old fashion paper. Even though I could go to > > various > > web > > > sites to look at account details, etc., I don't because it's not > > convenient > > > to the way I want to work. > > > > BTW, however, I do pay everything (and I mean everything...except my dry > > cleaner) with either AMX or via electronic payment through Quicken to > > CheckFree. No more checks/paper/cash! > > > > So....no right or wrong here....but herein lies a challenge....what DO > > these SME's want? > > > > Rachel > > > > -----Original Message----- > > From: Fred Blommestein, van [mailto:email@example.com] > > Sent: Monday, April 22, 2002 4:06 PM > > To: firstname.lastname@example.org; email@example.com; > > firstname.lastname@example.org; email@example.com > > Cc: firstname.lastname@example.org > > Subject: RE: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components... > > > > > > Rachel, > > > > I agree, that ultimately I would like to do everything automatically > > through my Quicken system. But what if Quicken (or whatever accounting > > system I have) does not support that (yet). Or doen't support that > > specific document or process. > > > > And you are wrong. I don't want merely to see the message on my monitor, > > I want to be able to retrieve more information if needed and give a > > response as well (and in the process I want my Quicken system to get the > > data it needs). > > > > Anyway what I need is a more flexible way of communication than receiving > > an electronic document that is a copy (but less readable) from the paper > > one. > > > > Fred > > > > <<< "Rachel Foerster" <email@example.com> 4/22 10:49p >>> > > Fred, > > > > Your concept seems to me to be one of requiring the receiver, i.e., the > > SME, to have to deal with the business message as a display on a monitor. > > That certainly doesn't get at the need to be able to automatically take > > the > > > data into a system. > > > > As an SME I don't want to view the message, I want to take the data into > > Quicken! I want to view it only after it's in my application system and > > then make business decisions, such as whether to post or not and then pay > > or not. A big difference. > > > > Rachel > > > > -----Original Message----- > > From: Fred Blommestein, van [mailto:firstname.lastname@example.org] > > Sent: Monday, April 22, 2002 3:41 PM > > To: email@example.com; firstname.lastname@example.org; > > email@example.com > > Cc: firstname.lastname@example.org; email@example.com > > Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components... > > > > > > Todd, others, > > > > I always understood that the added value of XML over EDI is that you can > > send XML to a simple browser, while for EDI you need expensive > > middleware. Yet the focus of ebXML seems to be a mere replacement of EDI, > > with expensive middleware, but only more complex. > > > > In my view ebXML will only be viable (but then very viable) if support > > for it is built in in operating systems and general utilities like > > browsers. > > > > To enable that, we should: > > - define a message service layer that is handled by (next version) > > browsers > > > (and mobile phones) > > - define browser (and mobile phone) compatible "patterns" or > > transactions. > > > > A browser compatible "pattern" takes into account that a message (that is > > crowded with non human readable codes) is not just sent to the other end, > > but that the receiver (or his stylesheet) may decide what information he > > needs to retrieve additionally from the sender to take the next step. > > > > So the "logical" transfer (e.g. send a purchase order) may behave > > technically as a dialog, resulting in the same commitment. > > > > The challenge is to let this be transparent for the sender, who doesn't > > know (and doesn't care) whether the message goes to an SME or a > > multinational. > > > > Any thoughts? > > > > Fred van Blommestein > > Berenschot - EP-NL - OpenXchange > > > > <<< Todd Boyle <firstname.lastname@example.org> 4/22 9:59p >>> > > Me too. > > > > Mike Rawlins wrote: > > >Excuse me, but I can't help but violently disagree with most of this > > >sentiment! > > >[...] > > >We need better solutions, not bigger sticks... > > > > > >Christopher Harvey wrote: > > >>...my 0.02 cents worth is to ask all involved to understand > > >> the needs of the SMEs but to use the big guys to force change. > > > > Here's one idea: a bettor's approach, or a PicoIPO: > > > > > > Dear SME Accounting Software vendor: > > > > I hereby offer to pay you to build a UBL interface on your > > product. You will offer it for sale to your users. > > > > Together we will calculate how many unit sales it requires > > for you to recover the cost of the development. You will > > repay me for my investment at a flat rate until you reach the > > breakeven sales. Then you will pay me another $1000 > > winnings, from any further incremental sales. Then you > > can keep the sales proceeds after that. > > > > Stop arguing which came first, the chicken or the egg. > > > > Here is an egg. > > > > Todd > > > > > > ---------------------------------------------------------------- > > The ebxml-dev list is sponsored by OASIS. > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.ebxml.org/ob/adm.pl> > > > > > > > > > > > > > > ---------------------------------------------------------------- > > The ebxml-dev list is sponsored by OASIS. > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.ebxml.org/ob/adm.pl> > > > > > > > > > > ---------------------------------------------------------------- > > The ebxml-dev list is sponsored by OASIS. > > To subscribe or unsubscribe from this elist use the subscription > > manager: <http://lists.ebxml.org/ob/adm.pl> > > -- > James Wydenbach > BitDaemons Ltd > http://www.bitdaemons.com > tel: +44 (0)1252 326402 > > ---------------------------------------------------------------- > The ebxml-dev list is sponsored by OASIS. > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.ebxml.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC