A profile (such as EPM) could have its own schema with greater precision
than the core, couldn't it? So even if the core just has <Options> as a
sequence of xs:any, that doesn't prevent the EPM profile from defining
<Options> as something more specific, which enumerates all the EPM options.
<ed>yes you are right</ed>
So I'm suggesting that if we keep doing what we're doing, for the core, you
can still get greater schema-typing in the profiles, if you want. Is that
good enough?
<ed>If there are not too many constarints on how a profile extends, then
yes.</ed>
>Finally, what is the team's stance on the first few profiles they have
>identified for co-publishing next July. If they have all their optional
>types and constructs published in the core they are not really profiles
>anymore, they are actually supported.
I'd say they're still profiles because they say *which* options are allowed,
and which aren't.
<ed>OK, I buy this definition. However in that narrow definition, the EPM
can no longer be called a profile.</ed>
> If a profile has everything it needs
>to proceed with implementation and need only define normative rules and
>usage examples, I don't call that a profile.
I'd call that a profile. The requirements doc also uses the term 'profile'
in this broader sense: "A profile can limit optionality, instantiate
abstractions, add new elements into extensibility points, and add
processing rules."
<ed>Then it sounds like you are voting for "B" as it applies to the core
itself and "C" for extending it ? Right ?</ed>
>My innocent assumption was more along the lines that a profile is really
and
>truly an extension.
>
>Perhaps we have both here ? Usage profiles supported by the schema AND
>extended profiles which stretch the schema ? Comments ?
I think a single profile might do both, or just one or the other.
<ed> OK, done. </ed>
