standards bodies, no, mapping standard, yes
I love small-to-medium businesses. I like the idea of a company with fewer than 100 employees, being managed thru risks and rewards by just a few business-savvy "real" people, as opposed to corporate-raised automatons. our economy gets much more benefits from these entities than the pure revenue or production statitistics tell us - like technological or production innovation and cultural enhancement. so, I'd like to see, and help, small business succeed in retaining or gaining as much market share as possible. and the reason this relates to web services is...
one of the major areas of the IT landscape that web services will be applied to is in business-to-business e-commerce, b2b. in contrast to b2c (business-to-consumer) e-com, where a business is presenting its information (catalogs, prices, etc) straight to customer, ie, thru a website, b2b commerce usually deals with computer/information systems of one company transmitting information directly to another. like sending purchase orders, invoices, etc.
traditionally, b2b e-com has been done thru EDI (electronic data interchange) and it's very expensive, usually the EDI providers charge on a per-byte basis. but since web services could do the same thing over a regular http protocol, all they need is an internet connection and they're ready for b2b.
now even if businesses are able to communicate with each other over the internet, they have to establish a common language, or format, for their messages. so they both agree what a purchase order looks like. up come the various standards bodies like ebXML, cXML, UBL, and industry standards like CIDX. all of these 'languages' do things differently, and overlap with each other in various locations. all of these formats were also developed by the giants in the market to fit their standard ways of doing business.
if you are a small business and you want to participate in the great Web Services/XML/Internet ecommerce bazaar, currently, you're forced to contort your own ways of doing business so that it is conducive to communication with others'. but that's what latching onto these standards would imply for small businesses. and they just don't have that kind of money to invest in a complex IT system to do it. the return, especially now in web services' infancy, is far to small.
I would argue that there needs to be, instead of, or in addition to, XML standards and standards bodies, another XML standard language which is used to describe the mapping of one XML format into another. if we, as a small biz, had a standard way to present our own format's translation into another, we would only ever have to create that translation once, and then make it publicly accessible to allow all users of the other format to easily translate into ours.
I had this idea because I've seen many 'data-mapping' products for mapping one xml format into another. when I considered what would be involved in creating one of those programs, I saw that a mapping file is really just another piece of data itself, albeit meta-data concerning two other pieces of data. if we standardized the way xml formats are described to each other, it should make XSLT programming a breeze, and allow better mapping products that could all use a standardized engine for their mappings.
it's not quite a SOAP-box, but it's something I've been mulling over. now it's one the record.
one of the major areas of the IT landscape that web services will be applied to is in business-to-business e-commerce, b2b. in contrast to b2c (business-to-consumer) e-com, where a business is presenting its information (catalogs, prices, etc) straight to customer, ie, thru a website, b2b commerce usually deals with computer/information systems of one company transmitting information directly to another. like sending purchase orders, invoices, etc.
traditionally, b2b e-com has been done thru EDI (electronic data interchange) and it's very expensive, usually the EDI providers charge on a per-byte basis. but since web services could do the same thing over a regular http protocol, all they need is an internet connection and they're ready for b2b.
now even if businesses are able to communicate with each other over the internet, they have to establish a common language, or format, for their messages. so they both agree what a purchase order looks like. up come the various standards bodies like ebXML, cXML, UBL, and industry standards like CIDX. all of these 'languages' do things differently, and overlap with each other in various locations. all of these formats were also developed by the giants in the market to fit their standard ways of doing business.
if you are a small business and you want to participate in the great Web Services/XML/Internet ecommerce bazaar, currently, you're forced to contort your own ways of doing business so that it is conducive to communication with others'. but that's what latching onto these standards would imply for small businesses. and they just don't have that kind of money to invest in a complex IT system to do it. the return, especially now in web services' infancy, is far to small.
I would argue that there needs to be, instead of, or in addition to, XML standards and standards bodies, another XML standard language which is used to describe the mapping of one XML format into another. if we, as a small biz, had a standard way to present our own format's translation into another, we would only ever have to create that translation once, and then make it publicly accessible to allow all users of the other format to easily translate into ours.
I had this idea because I've seen many 'data-mapping' products for mapping one xml format into another. when I considered what would be involved in creating one of those programs, I saw that a mapping file is really just another piece of data itself, albeit meta-data concerning two other pieces of data. if we standardized the way xml formats are described to each other, it should make XSLT programming a breeze, and allow better mapping products that could all use a standardized engine for their mappings.
it's not quite a SOAP-box, but it's something I've been mulling over. now it's one the record.
0 Comments:
Post a Comment
<< Home