Re: [sca-assembly] Re: [Issue 82] NEW ISSUE: Relax <component/> schema toallow <implementation/> anywhere

[David Booz <booz@us.ibm.com>]

WRT inflexibility, we have strong requirements to support creation of composites with a simple text editor. Since a text editor can't provide schema assistance, the human has to remember the order of the elements. That's where the inflexibility comes in. I know that not everyone in the TC shares this requirement.

I like the idea at the end of your email.

What if we moved the extension point into it's own element, forcing extensions to be child elements of this new element? And what if we forced the extension element to be a singleton and at the end of the list? Does this help?

If we end up hard coding the sequence of elements, I'd like to see implementation last in the list; serv, ref, prop and then implementation....but this might cause a UPA problem?


Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Anish Karmarkar ---09/23/2008 07:02:04 PM---The UPA problem occurs because we have (a) elements and extensibility points occurring in any order

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	David Booz/Poughkeepsie/IBM@IBMUS
Cc:	sca-assembly@lists.oasis-open.org
Date:	09/23/2008 07:02 PM
Subject:	Re: [sca-assembly] Re: [Issue 82] NEW ISSUE: Relax <component/> schema to allow <implementation/> anywhere

---

The UPA problem occurs because we have (a) elements and extensibility 
points occurring in any order (b) with the elements and extension points 
cardinality > 1 and (c) we use substitution groups (hopefully someone 
more knowledgeable about UPA will chime in and confirm or refute this).

I'm curious wrt what the flexibility buys us.
OR what is so inconvenient in saying: implementation comes first, 
followed by all the services (if any), followed by all the references 
(if any), followed by all the properties (if any), followed by extension 
points (if any). The order of service/reference/property isn't important 
as long as we pick *one* that we like.

Instead of:
<component ...>
   <service ...>
   <property ...>
   <service ...>
   <reference ...>
   <implementation ...>
   <property ...>
</component>

I think it is cleaner to have:
<component ...>
   <implementation ...>
   <service ...>
   <service ...>
   <reference ...>
   <property ...>
   <property ...>
</component>

Also, <implementation> has maxOccurs of "1" whereas <service>, 
<reference> and <property> are unbounded. To allow any order of those 
elements and still specify that implementation has maxOccurs of '1' 
would be doable in schema but it would look ugly. Something like:

<sequence>
   <choice minOccurs="0" maxOccurs="unbounded">
     <element name="service" type="sca:ComponentService"/>
     <element name="reference" type="sca:ComponentReference"/>
     <element name="property" type="sca:PropertyValue" />
   </choice>
   <element ref="sca:implementation" minOccurs="0" maxOccurs="1"/>
   <choice minOccurs="0" maxOccurs="unbounded">
     <element name="service" type="sca:ComponentService"/>
     <element name="reference" type="sca:ComponentReference"/>
     <element name="property" type="sca:PropertyValue" />
   </choice>
   <any namespace="##other" processContents="lax" minOccurs="0"
              		 maxOccurs="unbounded"/>
</sequence>


-Anish
--

David Booz wrote:
> The hard wired sequence you've shown below is where we started years 
> ago. That structure was deemed inflexible, and the choice was added. I 
> still agree with the notion that a flexible structure would be beneficial.
> 
> Since opening this latest issue, several schema experiments have been 
> attempted to arrive at a solution, but none of them has been successful 
> (UPA failures). I'm no longer certain if this issue is solvable given 
> schema rules AND where we have placed the extensibility points. I was 
> hoping you'd have a brainstorm.
> 
> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> 
> Inactive hide details for Anish Karmarkar ---09/23/2008 01:33:07 
> AM---I've always wondered why we have that choice. Apologies, Anish 
> Karmarkar ---09/23/2008 01:33:07 AM---I've always wondered why we have 
> that choice. Apologies, if this was discussed before and I have fo
> 
> 
> From:		 
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
> 
> To:		 
> David Booz/Poughkeepsie/IBM@IBMUS
> 
> Cc:		 
> sca-assembly@lists.oasis-open.org
> 
> Date:		 
> 09/23/2008 01:33 AM
> 
> Subject:		 
> Re: [Issue 82] NEW ISSUE: Relax <component/> schema to allow 
> <implementation/> anywhere
> 
> ------------------------------------------------------------------------
> 
> 
> 
> I've always wondered why we have that choice. Apologies, if this was
> discussed before and I have forgotten the reason.
> What's wrong with saying:
> <sequence>
>   <implementation />
>   <service minOccurs="0" maxOccurs="unbounded"/>
>   <reference minOccurs="0" maxOccurs="unbounded"/>
>   <property minOccurs="0" maxOccurs="unbounded"/>
>   <any minOccurs="0" maxOccurs="unbounded"/>
> </sequence>
> 
> Doesn't that make the UPA problem more manageable?
> OR what is the advantage of allowing service/ref/prop to occur in any order?
> 
> -Anish
> --
> 
> David Booz wrote:
>  > TARGET: Any version of the Assembly spec
>  >
>  > DESCRIPTION:
>  > The schema for <component/> and others requires <implementation/> to be
>  > the first child. This seems overly restrictive and should be relaxed.
>  >
>  > PROPOSAL:
>  > Move the <implementation/> element inside the <choice/> containing
>  > <service/>, <reference/> and <property/>.
>  >
>  >
>  > Dave Booz
>  > STSM, BPM and SCA Architecture
>  > Co-Chair OASIS SCA-Policy TC
>  > "Distributed objects first, then world hunger"
>  > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
>  > e-mail:booz@us.ibm.com
>  >
> 
>