> collection of constraints that comprise this Profile. I suspect by the
> time we're done with the substance we'll find that the form...
I don't think discussing profiles in general will in any way hinder this effort, there is good consensus on the approach so far. However I don't think it can be assumed that this profile will establish all of the use cases for profiles and so a higher level discussion with some other hypothetical use cases could be useful. There are a number that I can think of just off the top of my head.
> Jacob asks, "Can a CAP profile be a subset of CAP?" Yes, that's what a
> standard profile is, by the cited definition and by every usage of the
> term I've ever encountered. It's accomplished by asserting a set of
The RSS profile is a good example where there is no "subset" at all, only an "interpretation" of the spec.
> constraints and requirements which should or must be met within the
> broader constraints of the CAP spec itself. Thus messages that conform
Adding constraints and requirements does not create a subset. To create a subset, some of the optional and potentially required elements of the CAP spec would have to be dropped in the profile. Such as Profile X saying an area block can only have areaDesc and polygon elements, nothing else.
--
--
