Re: [camp] Groups - Component.docx uploaded

Gil,

Thanks! Your thinking is exactly like mine including many of the same questions. I've worked this in to my proposal draft at the link below. It's not complete (last section -- formal schema -- missing) but I hope we can discuss on the call. I've included a lot of examples to hopefully make it clear.

    https://www.oasis-open.org/apps/org/workgroup/camp/download.php/48810/camp-spec-v1.1-wd08-issue-4-ah-wip-v1.doc

My thoughts on your questions below. Some I don't know but I think we are all converging on something good!

The big question in my mind is how to deal with Platform Component Templates. There is no technical reason I see not to allow them to be specified, and to permit Assemblies (Templates) to refer to them. And in some cases it might make a simpler model -- e.g. a PaaS which creates you a repo but doesn't need any artifacts from you. Or a plain vanilla VM. The ACT (which is currently required, even in my proposal) feels unnatural here to me. (Though my mental model is evolving...)

The other thing to work out is how this relates to parameters (Adrian + your proposal). Should that be an additional attribute on the specification?

Talk to you all very soon.

Best
Alex

Should CAMP:
a.    Define none of these values (components, requirements)?
b.    Define “some” of these values? If so, is there a hierarchy of component types?
RE: discussion on vocabularies

AH: NO. i've put language to the effect that implementers SHOULD co-ordinate / namespace, and left it at that.

Do all Components require an id?

NO: currently "id" is only required when it is referenced. it is only used for reference so this seems right.

Do we want to support inline data (for CONTENT objects?
Is "type" value necessary? We could do the same thing by simply using either ‘href’ or ‘data’.

AH: maybe to inline data (currently yes, but I couldn't think of a good use case, and it raises question of formats; I've put it as a string not base64 which is a PITA -- for binary data a user would have to use a different file, which is arguably healthy)
AH: type not logically necessary, as server could infer the type from the attribute it is against, but currently I have it as required for simplicity; would be required if we had subtypes (e.g. to support base64)

Should Requirements be nested inside of Components (as shown in this document) or appear as a top-level objects in the DP?
If the answer to the above is “nested”, can Requirements that appear inside one Component be referenced by other Components?
If two or more Components reference the same Requirement what, if any, are the implications for the run-time instantiation of those Components (i.e. if two Components reference the same database requirement, do they bind to the same database on instantiation?)
Do all Requirements require an id?

AH: yes, i've put in support for nesting AND reference.
AH: i think in the proposal at present that id's are global in scope.
AH: i think the same requirement instance (by ID) should result in the same fulfillment in all reference instance. ie yes they bind to the same database. this needs to be made explicit.
AH: re "id", no -- as per component

END

On 10/04/2013 01:16, Gilbert Pilz wrote:

camp message