[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Change sets review
Nick, I think that fundamentally this is fine. I have some issues/questions, below, but otherwise I think it's helpful conceptually and goes in a direction we'd want all tools to go some day.
Servers MAY refuse to construct a
- Is (reference: Dublin Core) the correct way to reference, or is that text in there provisionally?
- dcterms:identifier -
A unique identifier for this
- dcterms:modified - Each resource SHOULD have one instance of this property. Really? I should think that the most common scenario is a change set is created but not yet modified. Or is modified = created in that case?
- A type of configuration that accepts this configuration as a contribution. The hyperlink on accepts does not seem to be valid.
- A type of configuration that is acceptable as a contribution to this stream. Same thing - hyperlink wrong.
- Accepts/Accepted By - Are these really valid? I should think once you've specified overrides you pretty much commit to a particular configuration and the change set can't be applied elsewhere. Of course maybe I don't really understand how these are supposed to be used.
- oslc_config:component - If the change set overrides a particular configuration, then shouldn't that configuration's component reference be sufficient? I'm thinking this property is redundant; maybe that's OK.
- oslc:instanceShape - Once again, shouldn't this simply refer to the instance shape of the overridden configuration?
- I think you should add the term Selection to the Terminology section of the overview document. And change set, for that matter. I'm a visual learner and would benefit from having a diagram to illustrate how the terms apply - baseline, stream, configuration, etc. Do you have such a diagram? I can create one for you if you want. It would help me visualize all these concepts. Is there a tool that OASIS recommends for such diagrams?
oslc_config:selects - Perhaps One-or-many? Well OK, maybe we should say in the Description that not having a selects value means this selection is a noop. Similarly for oslc_config:selections in the changeSet vocabulary.
oslc_config:selects Range - why not specify the valid values in the Range column rather than having a detailed description that lays out all the options?
Make sure you add Removals and RemoveAll to the vocabulary.
That's all I have for now.