On Sun, 26 Oct 2003, Martin Stecher wrote:
I am changing parameter definitions to TDM. This is what I have so far:
am-part: extends atom;
Yes.
am-parts: extends list am-part;
This looks awkward, does not it? How about:
am-parts: extends list of am-part;
HTTP-Profile: extends Feature with {
[Aux-Parts: am-parts];
[Wont-Use-Body: size];
[Pause-At-Body: size];
[Content-Encodings: codings];
};
Yes.
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 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>
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.
OCP does not distinguish quoted and unquoted values on a semantical
level.
HTH,
Alex.