OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Many small standards versus one, large standard?

Hi Folks,

Ø  while JSON’s “simplicity is a virtue” approach led to widespread adoption,

Ø  under-specification has led to a proliferation of interoperability problems

Ø  and ambiguities. From a strictly software engineering perspective these

Ø  ambiguities can lead to annoying bugs and reliability problems, but in a

Ø  security context such as JOSE they can be fodder for attackers to exploit.

So it would seem that a standard that is completely specified is a good thing.

But completely specifying anything is complex. And lengthy.

Who has time to read (and understand) lengthy, complex specifications?

A solution: narrow the focus/scope of the standard. That reigns in its length and complexity. But then multiple standards are needed to accomplish anything. And perhaps those standards are contradictory and/or overlapping in places. If there was one large specification, we could ensure that inconsistencies and duplications are eliminated.

Sigh … many small standards (simple individually, but collectively complex) versus one large, complex standard.

I don’t see a winning strategy. Do you?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS