RE: [dss] Core versus Extended Profile Handling

["Edward Shallow" <ed.shallow@rogers.com>]

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>