RE: [dss] Core versus Extended Profile Handling

[Trevor Perrin <trevp@trevp.net>]

At 02:37 PM 11/6/2003 -0500, Edward Shallow wrote:

>[...]
>We have taken great pains to ensure our WSDL can be used to create
>consumption stubs using the most popular generators including IBM's WSTK,
>Sun's Jax-RPC, TME's Glue, MS's .Net, etc ... My point is that these
>generators do not repsond well to vagueness (e.g. choice, any, etc ...) They
>are generating language-specific object representations of the WSDL (and
>underlying schema) constructs.

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.

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?



>Thus any steps we can take to define our core and our profile with greater
>precision and specificity, the esaier it will be for our clients to consume
>our services.
>
>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.


>  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."



>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.

Trevor