RE: [dss] Core versus Extended Profile Handling

[Trevor Perrin <trevp@trevp.net>]

At 09:55 PM 11/6/2003 -0500, Edward Shallow wrote:
>Content-Transfer-Encoding: 7bit
>
>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>

For the core, I'm voting to keep it as-is.  I.e. <Options> is a sequence of 
<xs:any>, and there's a bunch of core options that profiles can pick and 
choose from, or add their own (your "B" lists some options under <Options> 
and then has a catch-all, but I don't quite see the point of that).

As for profiles - I'm not totally sure what option "C" means, could you 
elaborate (since this is your choice as well)?

I was thinking a profile might just be some text that says "these 3 core 
options are allowed, and this core option is mandatory, and this profile 
option is allowed".

If you wanted to translate that into a schema, you would translate the 
<Options> element as an <xs:all> of the option elements.  In other words, 
there would be no ordering constraints on the options (in fact, we should 
*insist* that profiles not add ordering constraints).

How does this fit with your thinking?

Trevor