[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Representation Types Alternatives
CC has made a decision on the Representation Types. I hope that we will be able to publish all our documents no later than sometime next week. Then you can look over the list (it's in the Naming Conventions document) and submit your comments to us. We think we've chosen correctly, but maybe not! Mary Kay -----Original Message----- From: Stuart Campbell [mailto:stuart.campbell@tieglobal.com] Sent: Wednesday, April 11, 2001 4:40 PM To: rawlins@metronet.com; 'ebXML-core' Subject: RE: Representation Types Alternatives Mike In answer to your question, no i am referring to representation type We can add to them, change them, delete them - but at the moment, when reading QA report, you will find that there are issues like 'what the hell do i do with them and how do i really make them'. I can tell you that i for one, and im not alone, really admire the effort in CC but equally have not got a clue how i can employ this valuable work. We can have 5 or 50 of them, i really dont care, but if they are never used it really doesnt matter - it will be just another standards document which sits on the shelf somewhere Stuart -----Original Message----- From: Mike Rawlins [mailto:rawlins@metronet.com] Sent: Wednesday, April 11, 2001 17:34 To: 'ebXML-core' Subject: Re: Representation Types Alternatives If you're referring to the discussion about paying for standards, I agree that is a minor discussion. If you're referring to representation types, I think this is a fundamental issue that needs to be resolved in whatever is approved for Vienna. Mike Stuart Campbell wrote: > I have to say that although an interesting an important area, there are a > lot more things which are important to resolve in core-components > deliverables right now. We're drilling into detail here with out hitting > the basics like 'how do i use core components' > > I think it would be astute to store up these comments and put more focus on > get the CC spec perfect and then have long discussion on these detailed > subjects > > Just a thought > > [personal, not a qa comment btw] > > Regards > > STUART > Technical Strategy Director, Technical Strategy Team > Business Development Unit > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Stuart Campbell > TIE Holding NV > UK T:+44 1270 254019 F:+44 7971 121013 > Netherlands T:+31 20 658 9335 F:+31 20 658 9901 > Global M:+44 7970 429251 E:stuart.campbell@TIEGlobal.com > W:www.TIEglobal.com P:www.stuartcampbell.co.uk > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -----Original Message----- > From: Probert, Sue [mailto:Sue.Probert@commerceone.com] > Sent: Tuesday, April 10, 2001 21:46 > To: 'tboyle@rosehill.net' > Cc: ebXML-core > Subject: RE: Representation Types Alternatives > > Todd > > Until very recently I was in a very similar position as a VSE (Very Small > Enterprise). I agree with you on the principles involved and I reckon it > hurts larger organisations as well. I believe strongly that if we are to > follow standards as respected as ISO then we should be able to arrange with > them to have access to stnadards documents at least to study whilst doing > our work. Most NGOs are open to this approach but in this case even as a > member of ISO TC154 I haven't actually approached ISO on this yet with > respect to our interest in 11179. So, to be fair, we shouldn't criticise > them at this stage. > > All UN/CEFACT documents are available freely and completely free of charge. > > Sue > > Sue Probert > Director, Document Engineering > Commerce One > Tel: +44 1332 342080 > www.commerceone.com > > -----Original Message----- > From: Todd Boyle [mailto:tboyle@rosehill.net] > Sent: 10 April 2001 20:44 > To: Probert, Sue; 'Blantz, Mary Kay'; rawlins@metronet.com > Cc: 'CRAWFORD, Mark'; ebXML-core > Subject: RE: Representation Types Alternatives > > Probert, Sue > > BTW I do not have a copy of 11179 as it is an extensive set of > > documents which ISO like to be paid for! Like most other ISO docs > > it is rarely at hand electronically. > > As a small business person I would like to formally protest > these EBXML activities based on copyrighted "standards" which > cannot be obtained without payment. > > This includes all of ISO, and it apparently includes all of > the X12 dictionary and supporting documents. This may also > include EDIFACT and X12 MIGs. Why are NGOs treated better than > software companies? > > It is inappropriate and systematically unfair, especially for > Quasi-governmental organizations like UN/CEFACT, to be setting > standards that individuals and small businesses will be required > to follow, but which cannot be understood without paying for > documentation. The cost of participating in ebXML and other > bodies is already excessive to small business, resulting in > disenfranchising them from the tradeoffs that are being made. > > Further, these pricing policies have the effect of driving away > technical and business domain participation, needed by ebXML. > > I'm fully aware standards work has economic costs. But charging > for copies of standards is the wrong way to recover them. > > The same situation exists in GAAP reporting: the AICPA and FASB > in the US are private organizations who set rules, which are > then strongly enforced by federal and state regulators. These > GAAP requirements cost approximately $500 per year to subscribe to. > But if I don't pay this money, it is de-facto impossible to > follow the rules. As a CPA I can lose my license, and be put in > prison if I don't obey every word of those rules, even when > preparing financial statements for nonpublicly listed companies. > > For your information, the result of this structure is that it > incents the private organization to needlessly churn the rules, > and to create unnecessarily complex rules, in order to maximize > their own roles and revenue stream. Many small practitioners > believe these incentives are a significant problem affecting > the AICPA and FASB. > > It is widely agreed that tax laws are driven by the same dynamic, > of intentional churn and rule complexity to garner economic gains > for particular industries. Churn and complexity are common strategic > tools in software companies to defend market positions, and have > been applied by the legal profession in some areas of commercial > law as well. > > Think about it. The "data standards" industry may have parallels. > What if nobody can even play the game until they are $30,000 invested > in the rules? Then they have incentives to prevent newcomers from > entering the industry for free. It's like a cancer. Actors in > the data standards wars already have enough incentives for complexity! > Now you have permanent standards bodies, requiring churn as their > revenue model. > > The key issues are fairness and goodwill, leading to wider adoption, > and simplifying standards by increasing transparency, and reducing > incentives for churn and complexity. > > Respectfully, > Todd BOyle CPA > Kirkland WA > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org -- Michael C. Rawlins, Rawlins EC Consulting http://www.metronet.com/~rawlins/ ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC