RE: [dss] Core versus Extended Profile Handling

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

Yeah, we are getting close on the Options front. My "C" was more for
additional request, and outputs structures that extended profiles might
need. I'll review the schema tommorrow and get back to you, I'm 3 hours
ahead of you here.

Goodnight zzzz  

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: November 6, 2003 10:49 PM
To: Edward Shallow; 'Rich Salz'
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] Core versus Extended Profile Handling

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