am-parts: extends list am-part;
This looks awkward, does not it? How about:
am-parts: extends list of am-part;
ok.
Should we use capital letters for types (Am-Parts rather than
am-part)? I do in OCP Core (e.g., "Feature" not "feature") but can
change to small letters if you prefer.
In 3.1 everything is lowercase. In section 9 we have uppercase and in
section 10 we have a mixture (bad that section title and text differ).
I think it looks well, if named parameter's names start with a capital
letter but type names are lowercase; then you know that the lowercase things
will be replaced by s.th. else while the capital words stay.
In order to define which tokens are defined as the am-part atoms, may I
still write:
am-part = "request-header"
/ "request-body"
/ "request-trailer"
/ "response-header"
/ "response-body"
/ "response-trailer"
in addition to the above?
I would render the above as a list in the text:
<t>This specification documents the following am-part
values:</t>
<list style="hanging">
<t hangText="request-header:">HTTP request headers
including ... as defined in ...</t>
...
</list>
ok. Thanks.
Or you can use a table (see texttable in P draft).
It is a semantic requirement, and the type can support extensions (or
not, depending on how you document it).
And what is codings now? Is it actually a list of tokens, as we used
it so far or a list of quoted-values? Or is it just a list of atoms
and implementations decide whether bare-values work here?
A list of atoms. Or a list of "coding", where coding extends atom with
some semantic properties.
I will then use:
content-coding: extends atom;
content-codings: extends list of content-coding;
The semantics of content-coding is defined in section 3.5 of <xref
target="RFC2616" />
Thank you
Martin