How do we handle SCA properties (was: Framework for StAX-based model loading)

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:

[snip]
> Thanks Frank for answering these questions. I have a few more that 
> maybe you or others could offer opinions on.
>
> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>
>> I don't know much about how the sca properties are configured, but I'll
>> try to answer your questions anyway.
>>
>>
>>> - As a user what steps do I need to take to provide custom data
>>> values for config properties? In a previous post, I listed an example
>>> of a concrete "Foo" class
>>>
>>
>> Option 1)
>>
>> Provide an XML schema completxType definition for the Type and let the
>> generator gen the impl including the deserialization support. In the
>> future, we plan to also let you provide a Java interface (with
>> annotations, if necessary) to define the type, and then have the
>> implementation class generated for you.
>>
>> The SDO generator will essentially generate the same Foo class that you
>> showed in the other thread, just with the addition of a base class
>> (DataObjectBase), and some get/set method overrides that implement
>> efficient switch-based reflective accessors - used by the generic XML
>> serializer/deserializer. If we also provide an option to generated a
>> loader, in the future, we could also provide an option to supress the
>> generation of the reflective accessors. The resulting class would no
>> longer be an SDO object in this case - but it would be easy to do as a
>> value-add feature in our generator (i.e., a -generateSimpleBean option).
>>
>> Option 2)
>>
>> Write the Foo implementation class yourself (or maybe generate it with
>> some other technology - like JAXB) and then simply register it as a
>> DataType with SDO. Remember that not all objects in an SDO model need to
>> be DataObjects. If you want non-DataObjects, they're modeled as 
>> DataTypes,
>> and you need to provide create from and convert to String methods for
>> them.
> I think option two is the more appealing one for applications 
> developers. I read option 1 to require a schema, which we may be able 
> to do for extensions, but is a bit much to ask application developers 
> to produce.

Jim, I'd like to initiate a new thread of discussion on property types 
and property configuration, because I think that you're bringing up very 
good and interesting points here and we're going to have to explore that 
space, which is not really covered by the SCA spec at the moment.

I agree with you that option two is much more appealing to (Java) 
application developers. If I'm a Java developer writing POJO components 
I probably just want to write Java classes for my complex properties, I 
don't want to write an XMLSchema at all. On the other hand, if I'm a 
BPEL developer, or writing XSLT components for example, chances are that 
I'll actually prefer to write an XMLSchema. I think we need to support 
both use cases / populations of developers, like we do for service 
interfaces with Java interfaces and WSDL portTypes. I'm also starting to 
think that this should even be more extensible. Let's say I'm writing a 
Javascript component, a C++ component, or a Ruby component - just using 
Ruby as an example here, I don't have a Ruby component container in the 
back of my pocket :), will I want to define my property types as Java 
classes? as XMLSchema types? I'm not sure... I'd probably prefer to use 
the same programming language I'm using to implement my component.

So we have a lot to explore here, and I think that all these questions 
are really about finding the right programming model for defining and 
configuring properties of SCA components written in various languages. 
We also need to add another dimension to that. First we have to deal 
with the Java developer, the BPEL developer, the XSLT developer, the 
JavaScript developer etc. then we also have to deal with different data 
representations and binding technologies. For some languages, like BPEL 
for example, the data representation will probably be driven by what 
your BPEL engine expects, or for JavaScript what your JavaScript 
runtime/VM expects. For Java, we have multiple choices. Some people will 
want to use plain JavaBeans, others JAXB, others SDO, others ADB or 
XMLBeans etc. So again here, without even going into any implementation 
details of how to glue all these technologies together (and independent 
of whether or not we use our SDO databinding to load our SCDL files), we 
need to define how an SCA application developer, using Tuscany, will 
specify what form he wants for his properties...

Now back to the reality of the SCA 0.9 spec :) It currently only defines 
support for simple type properties and requires the type of a property 
to be expressed as an XML schema type. The <property> element is defined 
as follows: <property name="xs:NCName" type="xs:QName" 
many="xs:boolean"? default="xs:string"? required="xs:boolean"?/>* where 
xs:QName is the qualified name of an XML schema simple type.

Obviously we need to improve this, and maybe we can even provide some 
input into the spec with the work we are doing in Tuscany:
- first define what it means to support complex type properties (what 
types are allowed? what about special Java collection types, can you 
have pointers between properties etc.)
- decide if we want to use a type system that is independent of a 
component implementation language, or tie the types of properties to the 
component implementation language
- cover the scenario you first brought up where you just want Java 
classes and no schema at all
- cover the scenarios where you just want to use XML schemas
- define how an application developer chooses a databinding/representation
- define what happens when an application developer decides to mix in a 
single application multiple databinding technologies (or if that even 
makes sense at all...)

I'm probably missing many more questions/items here :) I just wanted to 
initiate this discussion which I think is important. Any thoughts?

-- 
Jean-Sebastien

Re: How do we handle SCA properties

[Jim Marino <ji...@gmail.com>]

On Mar 28, 2006, at 7:20 AM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
>>
>> On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:
>>
>>
>>> Jim Marino wrote:
>>>
>>> [snip]
>>>
>>>
>>>> Thanks Frank for answering these questions. I have a few more  
>>>> that maybe you or others could offer opinions on.
>>>>
>>>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>>>
>>>>
>>>>
>>>>> I don't know much about how the sca properties are configured,  
>>>>> but I'll
>>>>> try to answer your questions anyway.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> - As a user what steps do I need to take to provide custom data
>>>>>> values for config properties? In a previous post, I listed an  
>>>>>> example
>>>>>> of a concrete "Foo" class
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Option 1)
>>>>>
>>>>> Provide an XML schema completxType definition for the Type and  
>>>>> let the
>>>>> generator gen the impl including the deserialization support.  
>>>>> In the
>>>>> future, we plan to also let you provide a Java interface (with
>>>>> annotations, if necessary) to define the type, and then have the
>>>>> implementation class generated for you.
>>>>>
>>>>> The SDO generator will essentially generate the same Foo class  
>>>>> that you
>>>>> showed in the other thread, just with the addition of a base class
>>>>> (DataObjectBase), and some get/set method overrides that implement
>>>>> efficient switch-based reflective accessors - used by the  
>>>>> generic XML
>>>>> serializer/deserializer. If we also provide an option to  
>>>>> generated a
>>>>> loader, in the future, we could also provide an option to  
>>>>> supress the
>>>>> generation of the reflective accessors. The resulting class  
>>>>> would no
>>>>> longer be an SDO object in this case - but it would be easy to  
>>>>> do as a
>>>>> value-add feature in our generator (i.e., a -generateSimpleBean  
>>>>> option).
>>>>>
>>>>> Option 2)
>>>>>
>>>>> Write the Foo implementation class yourself (or maybe generate  
>>>>> it with
>>>>> some other technology - like JAXB) and then simply register it  
>>>>> as a
>>>>> DataType with SDO. Remember that not all objects in an SDO  
>>>>> model need to
>>>>> be DataObjects. If you want non-DataObjects, they're modeled as  
>>>>> DataTypes,
>>>>> and you need to provide create from and convert to String  
>>>>> methods for
>>>>> them.
>>>>>
>>>>>
>>>> I think option two is the more appealing one for applications  
>>>> developers. I read option 1 to require a schema, which we may be  
>>>> able to do for extensions, but is a bit much to ask application  
>>>> developers to produce.
>>>>
>>>>
>>>
>>> Jim, I'd like to initiate a new thread of discussion on property  
>>> types and property configuration, because I think that you're  
>>> bringing up very good and interesting points here and we're going  
>>> to have to explore that space, which is not really covered by the  
>>> SCA spec at the moment.
>>>
>>> I agree with you that option two is much more appealing to (Java)  
>>> application developers. If I'm a Java developer writing POJO  
>>> components I probably just want to write Java classes for my  
>>> complex properties, I don't want to write an XMLSchema at all. On  
>>> the other hand, if I'm a BPEL developer, or writing XSLT  
>>> components for example, chances are that I'll actually prefer to  
>>> write an XMLSchema. I think we need to support both use cases /  
>>> populations of developers, like we do for service interfaces with  
>>> Java interfaces and WSDL portTypes. I'm also starting to think  
>>> that this should even be more extensible. Let's say I'm writing a  
>>> Javascript component, a C++ component, or a Ruby component - just  
>>> using Ruby as an example here, I don't have a Ruby component  
>>> container in the back of my pocket :), will I want to define my  
>>> property types as Java classes? as XMLSchema types? I'm not  
>>> sure... I'd probably prefer to use the same programming language  
>>> I'm using to implement my component.
>>>
>>> So we have a lot to explore here, and I think that all these  
>>> questions are really about finding the right programming model  
>>> for defining and configuring properties of SCA components written  
>>> in various languages. We also need to add another dimension to  
>>> that. First we have to deal with the Java developer, the BPEL  
>>> developer, the XSLT developer, the JavaScript developer etc. then  
>>> we also have to deal with different data representations and  
>>> binding technologies. For some languages, like BPEL for example,  
>>> the data representation will probably be driven by what your BPEL  
>>> engine expects, or for JavaScript what your JavaScript runtime/VM  
>>> expects. For Java, we have multiple choices. Some people will  
>>> want to use plain JavaBeans, others JAXB, others SDO, others ADB  
>>> or XMLBeans etc. So again here, without even going into any  
>>> implementation details of how to glue all these technologies  
>>> together (and independent of whether or not we use our SDO  
>>> databinding to load our SCDL files), we need to define how an SCA  
>>> application developer, using Tuscany, will specify what form he  
>>> wants for his properties...
>>>
>>>
>> I'm wondering if now if the question isn't  a choice between  
>> Jeremy's approach and going with SDO ( or some other binding  
>> technology. Since we will need maximum extensibility to handle all  
>> of these different component types, It seems to me what we need is  
>> a "low-level" binding infrastructure that things like JAXB or SDO  
>> can plug into. Another way to view this would be the low-level  
>> infrastructure delegates to other binding technologies, which  
>> would allow us to support multiple binding solutions as opposed to  
>> just one at a time. This low-level infrastructure would be  
>> responsible for partially parsing the XML and delegating to a  
>> factories if necessary to instantiate property instances. I think  
>> this would allow for *multiple* binding frameworks as opposed to  
>> just one. Jeremy, do you think this is feesible and if so could  
>> you provide a sketch of how this would look in code?
>>
>>
> I was explicitly trying to create a different thread of discussion  
> here, on a different level. IMHO both the SDO based approach and  
> Jeremy's StAX approach can be made extensible and support pluggable  
> databindings and pluggable factories for properties. But again I  
> was trying to initiate a discussion of the actual scenarios for  
> using properties and requirements at the programming model level.  
> The SDO vs StAX discussion is an interesting discussion, but a  
> different one, and I'd prefer to continue it in its own thread, not  
> this one.
>
O.K. sorry I couldn't help myself. Can't we take the list of  
requirements last updated by Jeremy and fold the items you outlined  
here into them, changing the subject to the current?  I'm happy to do  
that if it works for you. I kind of think the two discussions are  
intertwined since the StAX vs. SDO is an issue related to how the  
requirements should be implemented.  I was trying to suggest the  
following:

- We must support a simple, easy bottom up extensibility story that  
feels natural in whatever implementation *major* language/programming  
model people are using.
- We also need to support a top-down approach. My opinion is the  
buttom up approach is more important given our user base but I don't  
think we should debate that.
- The most realistic way it seems to me that we can be successful in  
achieving support for such varied use cases is we have a "binding  
infrastructure" that is extremely open and not tied to a particular  
binding technology. I realize we need to go through the use cases in  
more detail before we arrive at this conclusion but I figured it  
would be useful to state prejudices up front
- Jeremy's StAX approach may provide this for us, with the ability to  
"layer" a variety of binding technologies on top. I definitely don't  
think we should conclude this yet. My intention was to point
out that we shouldn't necessarily presume it is StAX *vs.* SDO.

Anyway, do you want me to fold these into a requirements list?

>>
>>
>>> Now back to the reality of the SCA 0.9 spec :) It currently only  
>>> defines support for simple type properties and requires the type  
>>> of a property to be expressed as an XML schema type. The  
>>> <property> element is defined as follows: <property  
>>> name="xs:NCName" type="xs:QName" many="xs:boolean"?  
>>> default="xs:string"? required="xs:boolean"?/>* where xs:QName is  
>>> the qualified name of an XML schema simple type.
>>>
>>>
>> Yes, this was an area left for further work due to time constraints.
>>
>>> Obviously we need to improve this, and maybe we can even provide  
>>> some input into the spec with the work we are doing in Tuscany:
>>>
>>
>> Yea, we definitely need to improve since that level of support is  
>> kind of lame.
>>
>>
>>> - first define what it means to support complex type properties  
>>> (what types are allowed? what about special Java collection  
>>> types, can you have pointers between properties etc.)
>>> - decide if we want to use a type system that is independent of a  
>>> component implementation language, or tie the types of properties  
>>> to the component implementation language
>>>
>>
>> My opinion here is we want to go the language-specific route since  
>> we need to make working with properties natural to the  
>> implementation language. I think the most important goal of  
>> property configuration is to configuration points of variability  
>> on a specific implementation, not as a general representation of  
>> configuration data.
>>
> Yes, I agree with you for some use cases. If I'm going to write a  
> component in language X, I'd like to define my property types in  
> the same language X. On the other hand I can see other use cases  
> (e.g. top down scenarios) where I'm going to define a component  
> type without caring or even knowing about how it's going to be  
> implemented. I'm not sure which implementation neutral form/ 
> language I'll want to use to define the component properties. Will  
> I use XMLSchema? Any thoughts?
>
>
>>> cover the scenario you first brought up where you just want Java  
>>> classes and no schema at all
>>> - cover the scenarios where you just want to use XML schemas
>>> - define how an application developer chooses a databinding/ 
>>> representation
>>>
>> Jeremy, could you provide an outline of how the StAX work could  
>> enable this?
>>
>>> - define what happens when an application developer decides to  
>>> mix in a single application multiple databinding technologies (or  
>>> if that even makes sense at all...)
>>>
>>>
>> I think that makes sense based on the use case you brought up,  
>> e.g. a Java component that takes POJOs and a BPEL engine that only  
>> understands SDO.
>>
>>
>>> I'm probably missing many more questions/items here :) I just  
>>> wanted to initiate this discussion which I think is important.  
>>> Any thoughts?
>>>
>>>
>> This is good - I think we're hammering out some important things  
>> even if the discussion gets heated at times :-)
>>
>>> --Jean-Sebastien
>>>
>>>
>>>
>>
>>
>>
> -- 
> Jean-Sebastien
>
>

Re: How do we handle SCA properties

[Jean-Sebastien Delfino <js...@apache.org>]

Jim Marino wrote:
>
> On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:
>
>> Jim Marino wrote:
>>
>> [snip]
>>
>>> Thanks Frank for answering these questions. I have a few more that 
>>> maybe you or others could offer opinions on.
>>>
>>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>>
>>>
>>>> I don't know much about how the sca properties are configured, but 
>>>> I'll
>>>> try to answer your questions anyway.
>>>>
>>>>
>>>>
>>>>> - As a user what steps do I need to take to provide custom data
>>>>> values for config properties? In a previous post, I listed an example
>>>>> of a concrete "Foo" class
>>>>>
>>>>>
>>>>
>>>> Option 1)
>>>>
>>>> Provide an XML schema completxType definition for the Type and let the
>>>> generator gen the impl including the deserialization support. In the
>>>> future, we plan to also let you provide a Java interface (with
>>>> annotations, if necessary) to define the type, and then have the
>>>> implementation class generated for you.
>>>>
>>>> The SDO generator will essentially generate the same Foo class that 
>>>> you
>>>> showed in the other thread, just with the addition of a base class
>>>> (DataObjectBase), and some get/set method overrides that implement
>>>> efficient switch-based reflective accessors - used by the generic XML
>>>> serializer/deserializer. If we also provide an option to generated a
>>>> loader, in the future, we could also provide an option to supress the
>>>> generation of the reflective accessors. The resulting class would no
>>>> longer be an SDO object in this case - but it would be easy to do as a
>>>> value-add feature in our generator (i.e., a -generateSimpleBean 
>>>> option).
>>>>
>>>> Option 2)
>>>>
>>>> Write the Foo implementation class yourself (or maybe generate it with
>>>> some other technology - like JAXB) and then simply register it as a
>>>> DataType with SDO. Remember that not all objects in an SDO model 
>>>> need to
>>>> be DataObjects. If you want non-DataObjects, they're modeled as 
>>>> DataTypes,
>>>> and you need to provide create from and convert to String methods for
>>>> them.
>>>>
>>> I think option two is the more appealing one for applications 
>>> developers. I read option 1 to require a schema, which we may be 
>>> able to do for extensions, but is a bit much to ask application 
>>> developers to produce.
>>>
>>
>> Jim, I'd like to initiate a new thread of discussion on property 
>> types and property configuration, because I think that you're 
>> bringing up very good and interesting points here and we're going to 
>> have to explore that space, which is not really covered by the SCA 
>> spec at the moment.
>>
>> I agree with you that option two is much more appealing to (Java) 
>> application developers. If I'm a Java developer writing POJO 
>> components I probably just want to write Java classes for my complex 
>> properties, I don't want to write an XMLSchema at all. On the other 
>> hand, if I'm a BPEL developer, or writing XSLT components for 
>> example, chances are that I'll actually prefer to write an XMLSchema. 
>> I think we need to support both use cases / populations of 
>> developers, like we do for service interfaces with Java interfaces 
>> and WSDL portTypes. I'm also starting to think that this should even 
>> be more extensible. Let's say I'm writing a Javascript component, a 
>> C++ component, or a Ruby component - just using Ruby as an example 
>> here, I don't have a Ruby component container in the back of my 
>> pocket :), will I want to define my property types as Java classes? 
>> as XMLSchema types? I'm not sure... I'd probably prefer to use the 
>> same programming language I'm using to implement my component.
>>
>> So we have a lot to explore here, and I think that all these 
>> questions are really about finding the right programming model for 
>> defining and configuring properties of SCA components written in 
>> various languages. We also need to add another dimension to that. 
>> First we have to deal with the Java developer, the BPEL developer, 
>> the XSLT developer, the JavaScript developer etc. then we also have 
>> to deal with different data representations and binding technologies. 
>> For some languages, like BPEL for example, the data representation 
>> will probably be driven by what your BPEL engine expects, or for 
>> JavaScript what your JavaScript runtime/VM expects. For Java, we have 
>> multiple choices. Some people will want to use plain JavaBeans, 
>> others JAXB, others SDO, others ADB or XMLBeans etc. So again here, 
>> without even going into any implementation details of how to glue all 
>> these technologies together (and independent of whether or not we use 
>> our SDO databinding to load our SCDL files), we need to define how an 
>> SCA application developer, using Tuscany, will specify what form he 
>> wants for his properties...
>>
> I'm wondering if now if the question isn't  a choice between Jeremy's 
> approach and going with SDO ( or some other binding technology. Since 
> we will need maximum extensibility to handle all of these different 
> component types, It seems to me what we need is a "low-level" binding 
> infrastructure that things like JAXB or SDO can plug into. Another way 
> to view this would be the low-level infrastructure delegates to other 
> binding technologies, which would allow us to support multiple binding 
> solutions as opposed to just one at a time. This low-level 
> infrastructure would be responsible for partially parsing the XML and 
> delegating to a factories if necessary to instantiate property 
> instances. I think this would allow for *multiple* binding frameworks 
> as opposed to just one. Jeremy, do you think this is feesible and if 
> so could you provide a sketch of how this would look in code?
>
I was explicitly trying to create a different thread of discussion here, 
on a different level. IMHO both the SDO based approach and Jeremy's StAX 
approach can be made extensible and support pluggable databindings and 
pluggable factories for properties. But again I was trying to initiate a 
discussion of the actual scenarios for using properties and requirements 
at the programming model level. The SDO vs StAX discussion is an 
interesting discussion, but a different one, and I'd prefer to continue 
it in its own thread, not this one.

>
>> Now back to the reality of the SCA 0.9 spec :) It currently only 
>> defines support for simple type properties and requires the type of a 
>> property to be expressed as an XML schema type. The <property> 
>> element is defined as follows: <property name="xs:NCName" 
>> type="xs:QName" many="xs:boolean"? default="xs:string"? 
>> required="xs:boolean"?/>* where xs:QName is the qualified name of an 
>> XML schema simple type.
>>
> Yes, this was an area left for further work due to time constraints.
>> Obviously we need to improve this, and maybe we can even provide some 
>> input into the spec with the work we are doing in Tuscany:
>
> Yea, we definitely need to improve since that level of support is kind 
> of lame.
>
>> - first define what it means to support complex type properties (what 
>> types are allowed? what about special Java collection types, can you 
>> have pointers between properties etc.)
>> - decide if we want to use a type system that is independent of a 
>> component implementation language, or tie the types of properties to 
>> the component implementation language
>
> My opinion here is we want to go the language-specific route since we 
> need to make working with properties natural to the implementation 
> language. I think the most important goal of property configuration is 
> to configuration points of variability on a specific implementation, 
> not as a general representation of configuration data.
Yes, I agree with you for some use cases. If I'm going to write a 
component in language X, I'd like to define my property types in the 
same language X. On the other hand I can see other use cases (e.g. top 
down scenarios) where I'm going to define a component type without 
caring or even knowing about how it's going to be implemented. I'm not 
sure which implementation neutral form/language I'll want to use to 
define the component properties. Will I use XMLSchema? Any thoughts?

>> cover the scenario you first brought up where you just want Java 
>> classes and no schema at all
>> - cover the scenarios where you just want to use XML schemas
>> - define how an application developer chooses a 
>> databinding/representation
> Jeremy, could you provide an outline of how the StAX work could enable 
> this?
>> - define what happens when an application developer decides to mix in 
>> a single application multiple databinding technologies (or if that 
>> even makes sense at all...)
>>
> I think that makes sense based on the use case you brought up, e.g. a 
> Java component that takes POJOs and a BPEL engine that only 
> understands SDO.
>
>> I'm probably missing many more questions/items here :) I just wanted 
>> to initiate this discussion which I think is important. Any thoughts?
>>
> This is good - I think we're hammering out some important things even 
> if the discussion gets heated at times :-)
>> --Jean-Sebastien
>>
>>
>
>
-- 
Jean-Sebastien

Re: How do we handle SCA properties (was: Framework for StAX-based model loading)

[Jim Marino <jm...@myromatours.com>]

On Mar 24, 2006, at 4:21 PM, Jean-Sebastien Delfino wrote:

> Jim Marino wrote:
>
> [snip]
>
>> Thanks Frank for answering these questions. I have a few more that  
>> maybe you or others could offer opinions on.
>>
>> On Mar 24, 2006, at 12:10 PM, Frank Budinsky wrote:
>>
>>
>>> I don't know much about how the sca properties are configured,  
>>> but I'll
>>> try to answer your questions anyway.
>>>
>>>
>>>
>>>> - As a user what steps do I need to take to provide custom data
>>>> values for config properties? In a previous post, I listed an  
>>>> example
>>>> of a concrete "Foo" class
>>>>
>>>>
>>>
>>> Option 1)
>>>
>>> Provide an XML schema completxType definition for the Type and  
>>> let the
>>> generator gen the impl including the deserialization support. In the
>>> future, we plan to also let you provide a Java interface (with
>>> annotations, if necessary) to define the type, and then have the
>>> implementation class generated for you.
>>>
>>> The SDO generator will essentially generate the same Foo class  
>>> that you
>>> showed in the other thread, just with the addition of a base class
>>> (DataObjectBase), and some get/set method overrides that implement
>>> efficient switch-based reflective accessors - used by the generic  
>>> XML
>>> serializer/deserializer. If we also provide an option to generated a
>>> loader, in the future, we could also provide an option to supress  
>>> the
>>> generation of the reflective accessors. The resulting class would no
>>> longer be an SDO object in this case - but it would be easy to do  
>>> as a
>>> value-add feature in our generator (i.e., a -generateSimpleBean  
>>> option).
>>>
>>> Option 2)
>>>
>>> Write the Foo implementation class yourself (or maybe generate it  
>>> with
>>> some other technology - like JAXB) and then simply register it as a
>>> DataType with SDO. Remember that not all objects in an SDO model  
>>> need to
>>> be DataObjects. If you want non-DataObjects, they're modeled as  
>>> DataTypes,
>>> and you need to provide create from and convert to String methods  
>>> for
>>> them.
>>>
>> I think option two is the more appealing one for applications  
>> developers. I read option 1 to require a schema, which we may be  
>> able to do for extensions, but is a bit much to ask application  
>> developers to produce.
>>
>
> Jim, I'd like to initiate a new thread of discussion on property  
> types and property configuration, because I think that you're  
> bringing up very good and interesting points here and we're going  
> to have to explore that space, which is not really covered by the  
> SCA spec at the moment.
>
> I agree with you that option two is much more appealing to (Java)  
> application developers. If I'm a Java developer writing POJO  
> components I probably just want to write Java classes for my  
> complex properties, I don't want to write an XMLSchema at all. On  
> the other hand, if I'm a BPEL developer, or writing XSLT components  
> for example, chances are that I'll actually prefer to write an  
> XMLSchema. I think we need to support both use cases / populations  
> of developers, like we do for service interfaces with Java  
> interfaces and WSDL portTypes. I'm also starting to think that this  
> should even be more extensible. Let's say I'm writing a Javascript  
> component, a C++ component, or a Ruby component - just using Ruby  
> as an example here, I don't have a Ruby component container in the  
> back of my pocket :), will I want to define my property types as  
> Java classes? as XMLSchema types? I'm not sure... I'd probably  
> prefer to use the same programming language I'm using to implement  
> my component.
>
> So we have a lot to explore here, and I think that all these  
> questions are really about finding the right programming model for  
> defining and configuring properties of SCA components written in  
> various languages. We also need to add another dimension to that.  
> First we have to deal with the Java developer, the BPEL developer,  
> the XSLT developer, the JavaScript developer etc. then we also have  
> to deal with different data representations and binding  
> technologies. For some languages, like BPEL for example, the data  
> representation will probably be driven by what your BPEL engine  
> expects, or for JavaScript what your JavaScript runtime/VM expects.  
> For Java, we have multiple choices. Some people will want to use  
> plain JavaBeans, others JAXB, others SDO, others ADB or XMLBeans  
> etc. So again here, without even going into any implementation  
> details of how to glue all these technologies together (and  
> independent of whether or not we use our SDO databinding to load  
> our SCDL files), we need to define how an SCA application  
> developer, using Tuscany, will specify what form he wants for his  
> properties...
>
I'm wondering if now if the question isn't  a choice between Jeremy's  
approach and going with SDO ( or some other binding technology. Since  
we will need maximum extensibility to handle all of these different  
component types, It seems to me what we need is a "low-level" binding  
infrastructure that things like JAXB or SDO can plug into. Another  
way to view this would be the low-level infrastructure delegates to  
other binding technologies, which would allow us to support multiple  
binding solutions as opposed to just one at a time. This low-level  
infrastructure would be responsible for partially parsing the XML and  
delegating to a factories if necessary to instantiate property  
instances. I think this would allow for *multiple* binding frameworks  
as opposed to just one. Jeremy, do you think this is feesible and if  
so could you provide a sketch of how this would look in code?


> Now back to the reality of the SCA 0.9 spec :) It currently only  
> defines support for simple type properties and requires the type of  
> a property to be expressed as an XML schema type. The <property>  
> element is defined as follows: <property name="xs:NCName"  
> type="xs:QName" many="xs:boolean"? default="xs:string"?  
> required="xs:boolean"?/>* where xs:QName is the qualified name of  
> an XML schema simple type.
>
Yes, this was an area left for further work due to time constraints.
> Obviously we need to improve this, and maybe we can even provide  
> some input into the spec with the work we are doing in Tuscany:

Yea, we definitely need to improve since that level of support is  
kind of lame.

> - first define what it means to support complex type properties  
> (what types are allowed? what about special Java collection types,  
> can you have pointers between properties etc.)
> - decide if we want to use a type system that is independent of a  
> component implementation language, or tie the types of properties  
> to the component implementation language

My opinion here is we want to go the language-specific route since we  
need to make working with properties natural to the implementation  
language. I think the most important goal of property configuration  
is to configuration points of variability on a specific  
implementation, not as a general representation of configuration data.
> - cover the scenario you first brought up where you just want Java  
> classes and no schema at all
> - cover the scenarios where you just want to use XML schemas
> - define how an application developer chooses a databinding/ 
> representation
Jeremy, could you provide an outline of how the StAX work could  
enable this?
> - define what happens when an application developer decides to mix  
> in a single application multiple databinding technologies (or if  
> that even makes sense at all...)
>
I think that makes sense based on the use case you brought up, e.g. a  
Java component that takes POJOs and a BPEL engine that only  
understands SDO.

> I'm probably missing many more questions/items here :) I just  
> wanted to initiate this discussion which I think is important. Any  
> thoughts?
>
This is good - I think we're hammering out some important things even  
if the discussion gets heated at times :-)
> -- 
> Jean-Sebastien
>
>