4.2 Properties (editorial)

[Patrick Durusau <patrick@durusau.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings!

While I am using 4.2 as an example, these comments apply to the
structure of all the property definitions sections in TOSCA.

I get the impression, possibly wrong, that indented lists are being
used to represent parent/child, element/attribute relationships?

Yes?

If so, that makes reliable references very difficult. Witness my
comment on another issue that referred to 4.2 (Extensions). I didn't
know of any other way to indicate the sub-section I wanted to reference.

I don't think numbering the list would improve matters all that much.

Using second level sections for elements and third level sections for
attributes would go a long way to making it easy to refer back and
forth to various provisions in the specification.

It would not change the content, although the appearance would change
substantially.

Specific to 4.2, the change in the use of sections, sub-sections,
sub-sub-sections, would remove ambiguity like the paragraphs at 436 to
439, inclusive and 440 - 449, inclusive, 450 to 455, inclusive.

I can't tell if all of these paragraphs apply to Import or does the
middle paragraph apply to "The Definitions element..."?

The lack of sectioning makes it difficult to track your location in
the text.

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/

iQIcBAEBAgAGBQJSJh1gAAoJEAudyeI2QFGogNYQAPit6fkK0GFY8hg6lsyCE2Iu
vHwwjeqAxTil9mvasezZoBYbO8udnNNJb0fFg1U292Vv1JsKO9ptMOr/e7NSqIWB
JHMIHTD/PRloSKtkrkqr5CEgVdd0FE5+MVZUfBWJhBou2lEzQIy3DOZEhiPnlcFI
xm8A83/0TnhC2cL2fiCzRagRJx/Y+CpzIW7oU6Y3SkDNPiLUd7R40aR+YjER8bMe
N3gKzDFcSmP+C2HTYXw9DlxDRu5SJztJQ44frNAUD5QJKCpgRaxnKn423vZVu3JA
T5BLXB9FCuGpDAFuitVwt8BOQ+2FsqzVp1LVypBHV941azIKDdWtn+ir8b6GlGQw
N9tnrc2Fyd/ON7LyO4QXX6RbOy+SPVznU6XKJBNfYkEml/qOPoxdHIh5LbM6eAE7
lTo1oqfYPe0ik5SLtX17gaLGmf1HlIZ63JzHhLDRXAt1gAVPWTCP57k9wSjZh3ih
8GgP7MaFwIZ4DPOcpaZ1DQsgurY683285jVQQ0nI3vdWvOSLk7aGEhaWeL4af4GF
8GH4mdLjDTZH5ZFpfWopSWmep2nVfgK5JzIhWa4vHF2foTqSV+jC9UyvHWtqJldl
X8+/8VW96QQzy5TLEZojzg/faOW00kqu8u0QqDqws3cM2OT70kRHIzJs5HKNe7a2
FtqRE3SWI7vkc0eq8QaL
=o6fG
-----END PGP SIGNATURE-----