On Fri, 24 Oct 2003, Martin Stecher wrote:
Here are a few usage examples from OCP Core:
Uri: atom;
Service: structure {
Uri;
};
Services: list<Service>;
And here is how NO message can be declared using the above
declarations and current message declaration syntax:
name:
NO
anonymous parameters:
Services
named parameters:
[sg-id: Uni]
payload:
undefined
Some way that allows to show that there are optional named
parameters (none defined by core).
So, that it will allow the HTTP draft to define that
Http-Profile: Service
and that Aux-Parts is a named parameter of that structure.
Your proposed solution has the disadvantage that NO has Services
parameter, defined as a list of Service and in HTTP there is no
mapping from HTTP-Profile to Service and no hint that NO anonymous
parameter is being changed from Services to Http-Profiles.
Yes, I noticed that problem too. In addition to what you mention
above, it is bad that Http-Profile has to re-list Uri as a member.
Note that documenting with BNF does not solve it since NO message
definition still has Services. The only thing I could come up with is
inheritance-like approach, which I hesitated to propose as a starting
point. For example, in HTTP you would write:
Profile: structure <Service> {
[Aux-Parts: Am-Parts];
[Skip-Parts: Am-Parts];
};
Would that be clear enough? Or would you prefer:
Profile: structure Service with {
[Aux-Parts: Am-Parts];
[Skip-Parts: Am-Parts];
};
or
Profile: extends Service with {
[Aux-Parts: Am-Parts];
[Skip-Parts: Am-Parts];
};
Note that since there is only one way to merge anonymous parameters
and the order of named parameters is not important, the "inheritance"
is simply appending new params to old ones. No multiple inheritance is
supported.
Note that you can only extend structures, not atoms or lists.
Which one would you prefer? Any better ideas?
Alex.