- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Thu, 17 Oct 2013 13:15:02 -0400
- To: Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKcXiSrDRJu9mGns7UJmYBSmLZCLa6_p-xKV+N+VUSHYqjBKtA@mail.gmail.com>
On an different project I came across some useful text from NASA on this topic Source: http://www.egy.org/files/ROI_Study.pdf Taxonomy of Standards: It is important to understand the landscape of standards and how geospatial standards are classified. There are three main types of standards: 1) de facto standards, 2) de jure, or voluntary consensus standards, and 3) mandatory standards, such as health and safety or other regulatory standards.14 De facto standards are those that emerge in the marketplace of convention, rather than the accredited standards development process, and are usually proprietary. In contrast, the geospatial standards central to this study are de jure standards, and meet the criteria for open, voluntary consensus standards set forth in OMB Circular A-119. In the U.S., the National Technology Transfer and Advancement Act of 1995 (NTTAA) mandates the use of these standards by federal agencies, where applicable and advisable. (For a complete discussion on the taxonomy of standards, see Appendix A.) Meaning of “Open”: There has been a great deal of discussion in recent years about “openness,” as in the need for “open” systems, standards, specifications, open data formats, and open source software. In each of these examples, the meaning of “open” is both unclear and imprecise. Regarding standards development, “open” means standards that are developed in an open, consensual process where all stakeholders have been invited into the process.15 The American National Standards Institute (ANSI) process adds additional requirements for openness, requiring consensus or agreement among stakeholders and due process in the form of a ballot and appeals process. Furthermore, it requires parties that hold intellectual property rights (IPR) to identify themselves and any proprietary interest during the process of standards development. In the context of the OGC, specifications “open” means that standards and specifications: Are created and maintained in an open, collaborative process Are freely distributed and publicly available Are non-discriminatory and non-proprietary Are vendor and technology neutral [OGC]. It is useful to point out that “open source” is not necessarily synonymous with “open standards.” However, some similarities exist between “open source” and the OGC specifications. The concept of open source generally means access to the source code, but it also extends the traditional notion of property rights to include specific distribution rights. Software could be “open source” (e.g., Linux), but not implement or support “open standards” (particularly open GI standards). Software can also be proprietary and still support and implement GI-open standards. Furthermore, certain open source licensing schemes allow for the development and distribution of open source proprietary software. On Mon, Sep 9, 2013 at 10:52 PM, Manu Sporny <msporny@digitalbazaar.com>wrote: > On 09/09/2013 09:48 AM, Ricardo Varela wrote: > > Some of the existing regulations are there to contemplate "use cases" > > that some projects may not have had to face yet and I think its not > > so wise to quickly disregard them all as "no longer relevant" > > +1 > > > On that note: I think it's important to separate the different areas > > in WebPayments that have to do with payment technologies, regulation, > > and virtual currencies. > > +1 > > > I don't see why we have such a zeal in linking all of those together. > > Are we saying that there will be no WebPayments standard until we > > have fully operational virtual currencies? > > Definitely not. I don't think anyone is saying that all of this stuff is > linked together such that we can't make reasonable progress based on the > practicalities of the regulatory environment today. > > > In the meantime, my opinion is that it would be good that at least > > some parts of those web payments find their way to real users out > > there, even if they have to be built over the "old" payment > > infrastructures > > Yes, absolutely. As we've seen, even most of the virtual/alt currencies > layer over the old payment infrastructure. That's going to be the way it > is for decades to come. > > For those of you that are not familiar with the process of creating > world standards, what Ricardo is getting at is very important to > internalize. > > To make progress toward something that will be a world standard takes a > tremendous amount of focused effort. You have to be practical about it, > which means that only a handful of the things we're trying to address > are going to be addressed in the 1.0 specifications. In general: > > Troubled standards: > > 1. Place design purity over practicality (XHTML2) > 2. Don't have an active community behind them (GRDDL) > 3. Are more complex than the task requires (SOAP) > 4. Misunderstand the target audience (RDF/XML) > 5. Try to do too much (WSDL) > 6. Are created in the Working Group, w/ no industry feedback loop (P3P) > 7. Has a timeline that is not restricted (XHTML2) > > Successful standards: > > 1. Are messy, but solve real problems in a pragmatic way (HTML5) > 2. Have active communities behind them (CSS3) > 3. Are simple, elegant, and reuse what works (JSON) > 4. Understand the target audience (HTML5) > 5. Are focused (PNG) > 6. Are largely done by industry before a Working Group starts (JSON-LD) > 7. Has a restricted timeline (less than 4 years) to hit 1.0 (JSON-LD) > > If what Ricardo is saying is that we should focus on the latter 6 items > if we want the work that this group is doing to succeed, I couldn't > agree more. > > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Meritora - Web payments commercial launch > http://blog.meritora.com/launch/ > > -- Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman http://www.projectmanagementhotel.com/projects/opman-portfolio jpotvin@opman.ca Mobile: 819-593-5983 LinkedIn (Google short URL): http://goo.gl/Ssp56
Received on Thursday, 17 October 2013 17:15:50 UTC