tosca-comment

 View Only

Chapter 18 Conformance, "schema takes precedence..."

  • 1.  Chapter 18 Conformance, "schema takes precedence..."

    Posted 09-03-2013 15:13
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Greetings!

    The second sentence of the first paragraph in 18 Conformance reads:

    *****
    The TOSCA schema takes precedence over the TOSCA grammar (pseudo
    schema as defined in section 2.5), which in turn takes precedence over
    normative text, which in turn takes precedence over examples.
    *****

    It is normal to provide precedence of a formal schema over prose text.
    In fact, it is required by the OASIS TC process, 2.18 Work Product
    Quality, (7a)...

    *****
    Where any definition in these separate files disagrees with the
    definition found in the specification, the definition in the separate
    file prevails.
    *****

    In the normal case there is an XML schema + normative text and in case
    of a conflict, implementers must go with the XML schema.

    However, in TOSCA there is a series of cascading precedents, which
    leave implementers with not two choices but four choices to follow in
    constructing *interoperable* implementations.

    Effectively doubling the difficulty of implementers and greatly
    increasing the chance of a lack of interoperability.

    As the ODF editor, I am well aware of the long range consequences of
    under-specification. A similar form of lack of interoperability will
    arise from the four levels of conformance in the TOSCA specification.

    In terms of a fix, both for this issue and the other issue with
    paragraph 1 of section 18, I would have the separate schema, normative
    in cases of conflict with the normative text, then declare examples,
    notes and background material non-normative, label the normative
    sections and offer the traditional mandate, follow the schema in cases
    of conflict but otherwise the designated normative text.

    I would not use a separate grammar on the basis that it violates the
    DRY principle (Don't Repeat Yourself). Nothing good ever comes of
    repeated a formal specification, even if it can be formally validated
    as equivalent (which I think is still an open problem).

    Hope everyone is having a great day!

    Patrick


    - --
    Patrick Durusau
    patrick@durusau.net
    Technical Advisory Board, OASIS (TAB)
    Former Chair, V1 - US TAG to JTC 1/SC 34
    Convener, JTC 1/SC 34/WG 3 (Topic Maps)
    Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
    Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

    Another Word For It (blog): http://tm.durusau.net
    Homepage: http://www.durusau.net
    Twitter: patrickDurusau
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.11 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

    iQIcBAEBAgAGBQJSJfxuAAoJEAudyeI2QFGoEFgP/jFT4SeUKqgM7Fw1i30ZiiCG
    XpdiNaGu6mjlpWNvw9LIx/PpJlHgOs2R4vqNq7JYAilngbjU+vlWD0SnC0LyUeGl
    HHXCKlJHdbBk6KDSM/CUb1N/KkNbzyoFh6O2kgpoZbPG3FEeAJ/L8QQbuEdluJ21
    TgRoGQsdHpSadi2EBWi7JXhnLx4OyxZMm9SRtazsm6lVLLHf+dmZhZII8RpjqRmF
    VJ0lkU/rRh8AGTMciv6uYc88Qm90StJq6UuaweF81mUd8516Rpk5lSxALM8TSmQ/
    msWwmVQGOEx+GcALLEvlfGeKyO57SvUBboEPE0wDRlZij6orYNqohSBELYFfrG2I
    O3ZnoVgpxLMgRZ8yoQ39R/s/FaUsHSK5PKeF3au70EkqJWOHu5PUFbD0ng9DaYyT
    csMusRQWasHpwVIxdjgU3V388O4CDjA/pgihHOSBCM+2V4Xy74w5IweZ8IeXzieg
    Jj5UbhfWFP6nc2f0JK+fxCaQdPlhSVmpaC8g02qQ6vDI8innfHl9wpDs4At0Xyqv
    GZBKWlQapSyAef65FSSEldcGFbyxF0z22CYneQgJOHRfmCOwRj+IoLdby3tUhy7L
    inkUsWqFcMgNvuwZYotnQcE36AYHAGV2/XsRMnYt411xNk9anKMzYDPMvlF9Hu4N
    mfvbW/ZoxTmUXds9wkwC
    =X0Hp
    -----END PGP SIGNATURE-----