0 Replies Latest reply on Jul 1, 2015 6:49 PM by brmeyer

    Remove OASIS S-RAMP specification conformance?  (discussion)




      Getting right to it, the OASIS S-RAMP specification is essentially dormant/dead.  Unfortunately, many of the major players have recently mentioned that it's no longer relevant to their work, and the rest have been quiet.  The spec's models, Atom-based bindings, and conformance requirements introduce needless complexity and inflexibility.  The technical committee's JIRA instance has a long list of bugs (ones that realistically should be fixed through 1.0 errata) and numerous items that need enhanced and/or clarified.  Without interest in moving forward with a 1.1 or 2.0 release, its usefulness simply isn't going to be there.

      For Artificer 2.0, we're considering the following:

      1. Completely dropping conformance
      2. Replacing the artifact metadata models with something more flexible, powerful, and all-encompassing (instead of purely emphasizing SOA-related metadata)
      3. Replacing the Atom binding with JSON REST.  Several new features are hitting the limitations of Atom and require some really wonky hacks.  Switching to JSON for the core binding would clean up a lot of code.
      4. Maintain S-RAMP influences, such as the query syntax, certain pieces of metadata, constraints, errors, etc.


      I really think this would position us to be more flexible, as well as drastically simplifying the architecture and code.  However, I'd appreciate feedback if the S-RAMP spec is actually important to your use cases.  I'm not against maintaining bits of S-RAMP conformance through an optional plugin, but still moving forward with changing the core architecture.  Obviously, that's quite a bit of upfront work and long-term maintenance time, so we'd do that only if the community thinks it's necessary.


      Any opinions?