Mar 7th, Templates Minutes
Attendees:
Galen Mulrooney Grahame Grieve Ian Townend Mark Shafarman
Before the meeting Grahame sent out an email requesting a vote on two prepared motions to block-approve the dispositions on the A-T and A-Q ballot responses:
- 1: to approve the dispositions for all the A-T line items, namely
40,54,58,61,63,68,73,78,79,85,87,88,98,99,101,104,105,106,108 IT seconded 3/0/0
- 2: to approve the dispositions for all the A-Q line items, namely
17,25,33,37,46,75,95,102 IT seconded 3/0/0
Issue #2: Grahame moved Lloyd's comment be found non-persuasive, and that the following text will be inserted into the document per the discussion on the SPL mailing list: Under certain circumstances, when explicitly descirbed in the interface contract, applications are entitled to reject instances because unrecognized or unacceptable templates are associated with the instance, or if a template is not applied where it is expected
IT seconded 3/0/0
Issue #11: Grahame moved Lloyd's comment be found non-persuasive, because while it may be true that registration is not required, but if a tool claims to provide conformance to the registration role, it's not unreasonable to make rules about registration.
IT seconded 3/0/0
Issue #15: Grahame moved Lloyd's comment be found non-persuasive, because it is Ok to make rules for these roles - applications to not need to do these things
MS seconded 3/0/0
Issue #26: Grahame moved that the comment be found non-persuasive, because we are in violent disagreement that the entry point can be any class in the template.
IT seconded 3/0/0
Issue #27: Grahame moved that the comment be found non-persuasive, because we don't allow ad-hoc entry points and we're allowing stuff between the entry point in the model and the entry point in the template. MS seconded 3/0/0
Issue #28: Grahame moved that the comment be found non-persuasive, because we aren't allowing that kind of reference, and is described elsewhere in the document. We're not describing it here, because we don't allow the reference that the commenter is talking about. MS seconded 3/0/0
Issue #64: Grahame moved that the comment be found non-persuasive, because the comment seems orthogonal to the section which it is made on. The intent of the section is to limit the scope of templates to expressing constraints on RIM derived information models. Other things, like screen layouts etc are not in scope of this specification. The details of the comment fall into the scope of templates, not outside. I've tried to figure out how to rewrite the section to clarify, but I'm not sure what changes would be appropriate. IT seconded 3/0/0
Issue #70: Grahame moved that the comment be found non-persuasive, because while templates themselves provide meaning, but the mere fact that they are mentioned in the instance cannot be taken to provide meaning in the context of the instance (I have clarified the text a little). In a more general sense, implementation contexts or contracts may make templates mandatory, and may even choose to associate meaning with them, but in the end, to be conformant, the instance must be able to stand alone and be interpreted correctly without access to the template. In some ways this does constrain the usefulness of templates, but it's a matter of striking a balance between local and global interoperability IT seconded 3/0/0
Issue #110: Grahame moved that the comment be found non-persuasive, because while we appreciate the problem related to prior notification of upcoming content but this isn't a problem that can be solved in the standard by allowing this use of templateId. We do not have a good alternative to offer at this time, After much discussion, CfH is using a local extenison to trial this feature and may bring it forward for consideration at a later date. We decided to change the Template Specification to make it explicit that the template applies to the class that invokes it using the templateId and the implicit or explicit entry point class type of the template must match the class that contains the templateId. The templates specification must clarify how choices on the template entry point match the class of the invoking object. We asked the ITS Sig to consider ITS related solutions to this, but there was no solution identified. This has been discussed and resolved offline with the submitter. MS seconded 3/0/0
Issue #111: Grahame moved that the comment be found non-persuasive, because the comment seems orthogonal to the section which it is made on. The intent of the section is to limit the scope of templates to expressing constraints on RIM derived information models. Other things, like screen layouts etc are not in scope of this specification. The details of the comment fall into the scope of templates, not outside. I've tried to figure out how to rewrite the section to clarify, but I'm not sure what changes would be appropriate MS seconded 3/0/0
