With PaceProfileAttribute, weakening cardinality is possible with the strongly worded statement that new profiles SHOULD be defined so that they are backwards compatible with the core (thereby making weakened cardinality Not A Good Idea). Also, I would argue that if multiple profiles are allowed and are applied, the profile with the highest cardinality takes precendence. In other words, if someone declares that they are applying both the core profile and a profile that makes optional some element the core requires, the core takes precendence and the element is required.
- James M Snell
Eric Scheid wrote:
On 8/2/05 10:44 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
I'm not sure they are that antagonistic, but I agree with Paul when he says they could be added later. If profiles aren't supposed to matter to "Core Atom" processors, why not put our money where our mouth is and make profiles declare themselves in their own namespace?
would it be acceptable to use a profile to weaken cardinality rules?
for example, a profile for a (S)SFF (remember them?) would allow entries as minimal as this:
<entry> <id>some-id</id> <link rel="self" type="application/atom+xml" href="..." /> <updated>...</updated> </entry>
how might this be represented in a namespaced extension instead?
e.
