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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca-comment message

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


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


-----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-----


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