Slashdot Mirror

The standard says nothing about centuries, other than that the first two digits of a year can be used on their own to represent the century, for example the "century" component of 2005-12-15 is '20'. The ISO 8601 concept of a century is different to the vernacular, where we are in the 21st Century.

Nice rant, but the facts say otherwise. Check out the ebXML web site for some facts and you'll find it has wide support, was created under the chairmanship of IBM and is supported by key current electronic business project RosettaNet, a range of current players like CommerceOne and Documentum and of course OASIS, which is huge consortium with wide membership including Microsoft and IBM.

Maybe closer to the truth is that the openness of ebXML is a huge threat to the market strategy of Microsoft, offering among other things a standardised XML markup for business transactions (UBL) that undermines the standard-connections, proprietary-content trojan horse that their web services strategy is creating.

XML is good for industry standards bodies. It's open, there are open implementations, and you can irrefutably lay down the syntactic and semantic law in a schema without any ambiguity.

FpML, ArApXML, MDML are good examples of industry-specific XML standards. Going into the wider space, you get ebXML, SOAP and more.

XML is the new-world replacement for EDI (Electronic Data Interchange) and it's biggest uses are B2B and company-internal, with a small B2C following starting up for things like weather data, news feeds etc. It's not surprising you've not come across it... and until you go and work for a megalithic corporation on the IT side, you probably won't.

http://www.ebxml.org/

Consider a DNS registry. This isn't all that different. It is a considerably more complex, because it can describe a number of different services (see the notion of records in DNS though).

If you do make it a global registry, the concept of yellow/white pages makes sense: these are essentially just different queries against the database. You surely have used the White/Yellow Pages in your house?

As a developing standard, of course there is no RFC for this yet. It is still being hammered out - look at the specs!

Lastly, the argument regarding MS is somewhat empty... MS can't drive standards adoption on a B2B level - that's not their space. The only chance they have in driving these is by making them into community efforts. If MS is willing to spend money to do something good, why not take it???

As a side note, if you think this is a complex spec you should look at UDDI's superset: ebXML

If UDDI catches on, adherence will become mandatory. If that isn't good news to the legions of the unemployed tech workers, I don't know what is. Imagine if every one of those mom-and-pop shops suddenly realizes that their biggest customer will walk away unless they adopt this UDDI/ebXML thing...

Anotherwords, you people should be reading up on this and gaining some expertise pronto. Help spread the word.

However, one slight correction: Sun doesn't own ebXML. ebXML was created by UN/CEFACT (a division of the United Nations), OASIS (the consortium who owns xml.org) and a whole slew of companies, especially those with a heavy investment in EDI. I don't believe Sun's contribution was any greater than IBM's.

- Scott

What about XML-EDI, UDDI, EbXML (nice little article about the 3 initiatives)? Ok, it is not specifically aimed at groupwares but rather at distributed applications. But, on the other hand, are groupwares aimed at staying localized in just one area ? I'm not too sure. I believe groupwares will slowly mutate to an application server-like architecture where different parts will be build by different companies. Well apart from MS I mean...

Are perl programmers so fiercely anti-java that they will rally around and support A MICROSOFT AGENDA in order to make it go away? This is a dangerous set of priorities for one to have. Theres lots of other ways to send procedure calls via XML, including the competing, Sun-supported ebxml standard. And no reason why there cant be perl modules for that also. If youd prefer have everything be controlled by Microsoft and be rebooting Windows servers all day, rather than having to write some occasional Java code along with your Perl, then you're sick in the head.

Really, XML technology is so new I don't believe either or any XML standard or framework is established yet. In my experience with manufacturing and warehousing operations I've found that a surprisingly large number of them are still stuck on some expensive, proprietary VAX or IBM mainframe application that talks to nothing else, or even stick to pure paper systems. I've seen office assistants print off reports from the VAX and HAND TYPE the results into Excel to do sorts, calculations, graphs and so on--ridiculous!

What some people seem to lose sight of is that the whole concept of XML is extremely new if you can manage to see it from the perspective of everyone except geeks. The market for ebXML or BizTalk is almost completely untapped and too immature to make pronouncements on what will be in the future. Even Microsoft and IBM know that--while they are the prime backers of BizTalk, take a look under "I" and "M" in the ebXML List of Participants. That's right, there are contingents from both of them. How's that for hedging your bets?

In recent mails they are trying to layering the application using the XP standard.

By the way, Biztalk works? Yes, but after much effort. It didn't depend exclusively on the platform, that it's only a envelope.

We here have much experience in Biztalk, and I CAN TALK MUCH, MUCH MORE than M$. They have just Max Spencer that is just an internal integration of theirs POS. We make 3 pilot versions applied to 3 big business integrating Biztalk Jumpstart Kit, Biztalk Preview and Biztalk Beta. We TOO needed to use OUR criptography library to integrate the packages and our expertise to integrate the various ambients wich were mixed UNIX/Windows NT4/Windows 2000.

I can again reiterate that Biztalk is only an envelope with no type of messages include, that means that YOU need to create a standard message to exchange with your partners. You can use BASDA to exchange Orders and Invoices but and the other messages? If think that this is the end it's not, you need yet to integrate to your legacy system and it's not easy, IT'S A PROJECT !!!!

If this is not enough think about the cost of 3 machines and the software you need from M$ to run then to merely run Biztalk. These recommendations are that their papers I'm not kidding !!!

ebXML in the other way is derived of an effort of OASIS United Nations and I think they are doing the correct aproach.

They are not only describing the envelope but other needed things like how to describe the Order, Invoic, Remadv, Invrpt etc. They are describing then as business models not as messages. Describing business models are more effective then describe just messages. They are more flexible and compatible.

Others things are the Repository of these objects, Security and Transactions.

The simplicity of implementation of this aproach is been addressed to as you can see from that quotation of ebxml list discussion from Stefano Pogliani:

"And, still, we are talking about things that:

1. Are not monolithic.
   We can have modular piece of software, each devoted to a specific need. The idea here is that the generated piece of software will function as an "adapter" for the legacy application implementing the business functionality required by the b2b exchange.
   I do not see any need to "modify" the legacy, but only to "wrap" it (anyway the wrapping is logically required for plugging the Messaging layer...)
   
2. Are cheap.
   Granting interoperability at runtime grants that every vendor can jump onto the boat and propose a minimum set of common functionalities that are granted "regardless"...
   
3. Are well documented.
   I have been focussing in many discussions on different lists on the need to define the behaviour of the "collaboration model" agent (the BSI in [2]) as well as to define a clear XML vocabulary for expressing choreography information."

4. See more at ebXML site.