Tuscany IRC Log (April-24-2006)

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

(08:31:54 AM) *jsdelfino:* hi, all
(08:34:22 AM) *edslattery:* hi
(08:34:34 AM) *jsdelfino:* are we having our regular developer IRC 
discussion?
(08:38:24 AM) *jsdelfino:* just reconnected... I was thinking that we 
could discuss the plan for our may release, then the distributions we're 
going to have, and finally the outstanding JIRA issues that are blocking 
some of us
(08:39:19 AM) *jsdelfino:* also last week we've covered the SCA java 
tasks but not discussed any of the SDO and DAS work
(08:40:18 AM)* haleh [/n=hmahbod@c-24-6-102-194.hsd1.ca.comcast.net/] 
entered the room.*
(08:41:23 AM)* zx left the room (quit: Connection reset by peer).*
(08:41:54 AM)* zx [/n=zx@cpe-70-112-75-49.austin.res.rr.com/] entered 
the room.*
(08:42:00 AM) *jsdelfino:* any opinions? anybody there?
(08:42:59 AM) *kelvin-goodson:* hi, yes, sounds good
(08:45:10 AM) *Simon1:* do you mean SDO and DAS for java also?
(08:46:37 AM) *jsdelfino:* yes, we can also discuss the C++ work, we've 
not discussed any of the C++ stuff on the IRC yet, I think it would be 
good to have an idea of where we are and what's going into the May 
release for C++ as well
(08:46:46 AM) *robbins:* I guess so as we are not planning a C++ release 
in May
(08:47:47 AM) *jsdelfino:* ok :) so let's focus on Java then
(08:48:08 AM) *Simon1:* ok -sounds good - just checking
(08:49:47 AM) *jsdelfino:* for the Java release, the schedule is:
(08:50:14 AM) *jsdelfino:* - April 28th, all the major function should be in
(08:51:16 AM) *jsdelfino:* - then 2 weeks of testing / fixing
(08:51:55 AM) *jsdelfino:* I suggest that the first week we try to fix 
all blocker, critical, most major issues
(08:52:16 AM) *jsdelfino:* the second week we go into a much more 
controlled mode
(08:53:42 AM) *jsdelfino:* thoughts anyone?
(08:54:43 AM) *haleh:* are there blockers that need to be fixed before 
the 28th to allow others to progress?
(08:55:06 AM) *jsdelfino:* yes, I put them at the top of our Wiki page 
at: http://wiki.apache.org/ws/Tuscany/Tasks
(08:55:22 AM) *jsdelfino:* I believe that there are actually a few more
(08:55:32 AM) *jsdelfino:* but these are the ones we discussed on the 
last IRC on Friday
(08:56:25 AM) *robbins:* Are you planning to have a binary release or 
will this be a tag on the code in svn
(08:56:52 AM) *jsdelfino:* we'll have a binary release
(08:57:56 AM)* fbudinsky 
[/n=fbudinsk@CPE0004e2fcf7ef-CM023459906283.cpe.net.cable.rogers.com/] 
entered the room.*
(08:58:05 AM) *jsdelfino:* hi frank
(08:58:11 AM) *fbudinsky:* hi guys
(08:59:07 AM) *jsdelfino:* most people are silent today, I think that a 
number of people are in spec meetings, probably busy...
(08:59:49 AM) *fbudinsky:* has someone looked at the SDO config model yet?
(08:59:50 AM) *jsdelfino:* not sure we have enough active people to 
discuss the release plan, or the forms of distribution
(09:00:36 AM) *jsdelfino:* I think Jeremy was interested, since he was 
looking at something like an <import.sdo> and also volunteered to put 
together the sample demonstrating the use of SDO metadata
(09:00:42 AM) *jsdelfino:* would be good to have his input
(09:00:58 AM) *jboynes:* here - what are you looking for?
(09:01:24 AM) *jboynes:* I did look at the model but was not sure what 
was going on
(09:01:35 AM) *haleh:* we are OK with the release approach for SDO as well
(09:01:51 AM) *haleh:* ?
(09:01:51 AM) *jboynes:* I saw you check in some tests earlier today but 
have not had a chance to look at them yet
(09:02:49 AM) *fbudinsky:* that's unrelated ... the note i sent on the 
mailing list describes the config model ... and shows how a client calls it
(09:02:50 AM) *jsdelfino:* (confused) we have 3 parallel conversations now
(09:03:10 AM) *jsdelfino:* - frankb would like to discuss the config 
model / approach for importing SDO metadata
(09:03:13 AM)* robbins left the room (quit: Read error: 104 (Connection 
reset by peer)).*
(09:03:24 AM) *jsdelfino:* - haleh asking about the release approach for SDO
(09:03:54 AM) *jsdelfino:* - test cases? jboynes if you're talking about 
the test cases I checked in, they are WS test cases, nothing to do with SDO
(09:03:54 AM) *jboynes:* jsdelfino, sometimes that happens
(09:04:05 AM) *fbudinsky:* re: release of SDO ... I think it's fine same 
as sca
(09:04:35 AM) *jsdelfino:* jboynes, thanks for letting me know :)
(09:04:39 AM) *jboynes:* no, I thought fbudinsky added some as well
(09:04:39 AM) *fbudinsky:* i also checked in a test case this morning 
that i hope fixes the Linux problem TUSCANY-214
(09:05:18 AM) *jsdelfino:* frankb, jboynes, how do you think we 
integrate the import of SDO metadata?
(09:05:36 AM) *fbudinsky:* I couldn't test the fix for TUSCANY-214 
because it's only broken on Linux, but the symptoms looked like the 
infamous INSTANCE problem, so I hope it's fixed
(09:05:57 AM) *jboynes:* fbudinsky, why does INSTANCE only break on Linux?
(09:06:06 AM) *jboynes:* and is it linux or !windows
(09:06:45 AM) *jsdelfino:* ok now we have a 4th conversation thread :) I 
will test your fix on Linux right after this chat, but I have the same 
question, why would it happen only on Linux?
(09:06:50 AM) *jboynes:* I added support this PM for wsdlLocation on 
interface.wsdl
(09:07:07 AM) *fbudinsky:* take a look at my comment in TUSCANY-214 for 
what I speculate the problem might have been ... also if someone could 
confirm whether or not it's working now on Linux that would be good
(09:07:22 AM) *fbudinsky:* thanks sebastien
(09:07:28 AM) *jboynes:* so that wsdl defn's can be imported where they 
are used
(09:07:30 AM) *fbudinsky:* back to the metadata now ...
(09:07:41 AM) *jboynes:* :-)
(09:07:42 AM) *jsdelfino:* do you think that it's a timing issue? 
depends on the order in which the test cases are run?
(09:07:58 AM) *jboynes:* I'm thinking something similar for SDO
(09:08:19 AM) *fbudinsky:* the metadata model that i've created is a 
simple complex type (and corresponding global element decl) that can be 
used to package up one or more models that you want to register.
(09:08:29 AM) *fbudinsky:* what i had in mind is this ...
(09:09:17 AM) *jboynes:* jsdelfino, I have seen something in the past 
where getMethods() returns the methods in different orders resulting in 
test failures
(09:09:29 AM) *jboynes:* this was actually an issue on a jrockit VM
(09:09:40 AM) *fbudinsky:* you can embed an instance of one of these 
guys whereever is appropriate (??) and then before you try to use any of 
the required models you deserialize and call the register() method on 
the instance .... see the note i sent for more details
(09:10:39 AM) *jsdelfino:* fbudinsky, I confirm that your fix actually 
fixes the build break on Linux
(09:10:47 AM) *jboynes:* so we would add an <import.sdo> element and 
point it at one of these files?
(09:11:09 AM) *jboynes:* <import.sdo 
location="http://foo.org/sdo-stuff.xml">
(09:11:26 AM) *jsdelfino:* I will close JIRA issue 214
(09:11:32 AM) *fbudinsky:* cool :-) i think it is an order of execution 
difference in the two environments then
(09:11:38 AM) *jsdelfino:* yes
(09:11:56 AM) *fbudinsky:* jboynes ... yes that's the basic idea
(09:13:03 AM) *jsdelfino:* is <import.sdo> going to use frank's model?
(09:13:31 AM) *jboynes:* it's going to use some utility class he 
provides I hope
(09:14:48 AM) *fbudinsky:* i can give you a utility class if that's what 
you want ... but take a look at what's there first ... i think there's 
only 3 lines of code that you would need to write as it is
(09:16:49 AM) *jsdelfino:* frank, would the 3 lines of code use the 
model you posted on the dev list? or XSDHelper.defineType()?
(09:18:04 AM) *fbudinsky:* the model i posted is all you need ... 
XSDHelper.define() is called by it ... so you don't need to deal with 
that directly
(09:19:17 AM) *jboynes:* I don't understand what the different things in 
that model are
(09:19:18 AM)* robbins 
[/n=Robbins@host81-146-65-16.btremoteinternet-dsl.bt.net/] entered the 
room.*
(09:19:40 AM) *jboynes:* I was kind of hoping I could just import an XSD 
instance
(09:20:07 AM) *jboynes:* <import.sdo location="http://foo.org/foo.xsdl">
(09:20:08 AM) *jboynes:* <import.sdo location="http://foo.org/foo.xsdl">
(09:20:10 AM) *jboynes:* <import.sdo location="http://foo.org/foo.xsd">
(09:20:14 AM) *jboynes:* finally
(09:20:53 AM) *fbudinsky:* if that's all you need, then you don't need 
the config model ... and you can just call XSDHelper.define() for each 
wsdl/xsd
(09:21:16 AM) *jboynes:* I thought that only worked with dynamic types
(09:21:38 AM) *fbudinsky:* the config model is to allow you to also 
handle generated models or models defined using other kinds of metadata
(09:22:18 AM) *jsdelfino:* with <import.sdo> wouldn't you need to 
specify the name of the generated factory?
(09:22:38 AM) *fbudinsky:* that's the issue ... if the model is 
generated, then instead of dynamically registering the metadata you need 
to register it via the generated class
(09:23:42 AM) *jboynes:* <import.sdo 
factory="com.foo.SomeSDOSpecificFactoryClassIHaveNoIdeaWhatItDoes"/> ?
(09:24:29 AM) *fbudinsky:* what do you suggest instead?
(09:24:48 AM) *jboynes:* not sure what we can do
(09:25:11 AM) *jboynes:* trying to think what the user would normally be 
using
(09:25:31 AM) ****kelvin-goodson* is away: I'm busy
(09:25:31 AM) *fbudinsky:* the basic idea is that a factory is a a 
factory for a bunch of types (all in the same namespace)....
(09:25:49 AM) *fbudinsky:* by registering a factory, you register the 
namespace and all the associated generated classes
(09:25:53 AM) *jboynes:* is that an SDO thing or something from our impl?
(09:26:25 AM) *fbudinsky:* if you don't have a factory ... in the future 
... you will be able to register the list of generated classes 
themselves ... but that's not working yet
(09:27:03 AM) *fbudinsky:* please clarify what you mean by SDO thing or 
something ...
(09:27:05 AM) *jboynes:* trying to think what the user would normally be 
using
(09:27:10 AM) *jboynes:* e.g....
(09:27:26 AM) *jboynes:* in my impl do I write something like:
(09:27:54 AM) *jboynes:* Foo foo = (Foo) 
typeHelper.getType(Foo.class).newInstance() ?
(09:28:02 AM) *jboynes:* s/do/can/
(09:28:10 AM) *jboynes:* or
(09:31:08 AM) *fbudinsky:* you can do the first one makes no sense 
because a Type is not a java.lang.class ... you can always do the second 
one ... you can only do the third one if you have generated (or hand 
written in the future) static classes
(09:31:29 AM) *haleh:* Is our today's IRC a free form chat or is there a 
subject to discuss?
(09:31:37 AM) *fbudinsky:* the 4th approach is to call 
FooFactory.createFoo(), if you have a generted factory ... whcih we 
generate by default
(09:32:05 AM) *jboynes:* is that part of the SDO spec?
(09:32:07 AM) *jmarino:* I thought this was freeform
(09:32:42 AM) *jsdelfino:* haleh, we are discussing the sdo metadata 
story right now
(09:32:47 AM) *ant__:* I have to leave 'early' sorry. I should be back 
on IRC after 22:30BST, there's a couple of issues I'd like to discuss if 
jboynes and/or jsdelfino have any time after then
(09:32:53 AM)* ant__ is now known as ant_away*
(09:33:28 AM) *fbudinsky:* it's not in the spec ... it's an extension 
... but the codegen part of SDO is also not very well speced out either 
... and talking to the spec people the generated factory is in line with 
future direction ... it's the most efficient way to create instances
(09:34:19 AM) *jsdelfino:* and IMO it's also easier to use
(09:34:43 AM)* edslattery left the room (quit: Read error: 104 
(Connection reset by peer)).*
(09:34:45 AM) *jsdelfino:* Account account=factory.createAccount();
(09:35:02 AM) *jsdelfino:* instead of Account 
account=(Account)dataFactory.create(Account.class)
(09:35:14 AM) *fbudinsky:* also much cleaner than new FooImpl ... if you 
use the Interface/Class split pattern which is the recommended one for sdo
(09:36:39 AM) *jboynes:* would that work?
(09:36:42 AM) *fbudinsky:* also by definition Account.class is the 
interface class not the impl class. So unless you don't use the 
inteface/impl separation pattern, it needs to do a look up for the impl 
class
(09:37:09 AM) *fbudinsky:* yes it works, but like i said is inefficient
(09:37:48 AM) *jsdelfino:* sorry, would what work?
(09:37:58 AM) *jboynes:* Account 
account=(Account)dataFactory.create(Account.class)
(09:38:16 AM) *jboynes:* aiui, yes but its inefficient
(09:38:18 AM) *jsdelfino:* it works today
(09:38:43 AM) *jboynes:* aiui only if you call registerStaticTypes
(09:39:31 AM) *jboynes:* is that right?
(09:39:36 AM) *jsdelfino:* yes, sure, that's what we're discussing now I 
guess, a way to get the types registered without having to call 
SDOUtil.registerStaticTypes
(09:39:38 AM) *fbudinsky:* yes that's right
(09:39:58 AM) *jboynes:* jsdelfino, yes
(09:40:27 AM) *jboynes:* we want to support these API calls form the 
spec (efficiently)
(09:40:34 AM) *jboynes:* yes?
(09:40:45 AM) *fbudinsky:* yes
(09:41:37 AM) *jboynes:* we provide an extension for users where we 
generate a factory, so we're into something like
(09:41:59 AM) *jboynes:* <import.sdo factory="com.foo.FooFactory"/>
(09:42:23 AM) *fbudinsky:* that's what we have support for today
(09:42:29 AM) *jboynes:* not in SCA :-)
(09:43:02 AM) *fbudinsky:* right just in SDO :-)
(09:43:09 AM) *jboynes:* and can we associated the factory with a 
specific type helper?
(09:43:19 AM) *jboynes:* or is it implicit by TCCL?
(09:44:20 AM) *fbudinsky:* implicit by TCCL for now ... but that's what 
i'd like to try to fix with a combination of the config model and the 
new codegen patterns we're working on ... but that's not going to be in 
time for the JavaOne release
(09:45:11 AM) *fbudinsky:* the config model is a wrapper for a factory 
like this ... where you call a register method (passing a typeHelper ... 
and optioanlly a classLoader)
(09:45:48 AM) *fbudinsky:* that's the direction i'd like to see it move in
(09:46:31 AM) *fbudinsky:* it's also a wrapper for dynamic models ... so 
he can package up and register multiple models in on shot if you want
(09:46:54 AM) *fbudinsky:* some static some dynamic
(09:47:00 AM) *jsdelfino:* DataFactory.INSTANCE works off the TCCL right?
(09:47:38 AM) *jboynes:* I would be concerned that SCA loses control of 
what is being defined in its applications
(09:47:59 AM) *jboynes:* we're already seeing that with WSDL
(09:48:10 AM) *jsdelfino:* but what if you create your own DataFactory 
instance, associated with a specific TypeHelper? can we have a 
DataFactory scoped per module?
(09:48:18 AM) *jboynes:* as in, we import a WSDL and anythiny can happen
(09:48:41 AM) *jsdelfino:* jboynes, what do u mean by we import a WSDL 
and anything can happen?
(09:48:58 AM) *jboynes:* when you throw in composites we need type 
helpers scoped to composition units
(09:49:13 AM) *jsdelfino:* +1000 :)
(09:49:25 AM) *jboynes:* wsld has an extension model and we have no idea 
what those extensions do
(09:49:55 AM) *jboynes:* aiui that is how dkulp's celtix binding is 
doing jaxb definitions
(09:50:11 AM) *jboynes:* I would assume our sdo impl would go the same way
(09:50:19 AM) *jsdelfino:* would it be easy to have scoped typeHelpers 
today? maybe I'm missing something but I don't see anything preventing 
us to use composite-scoped type helpers
(09:50:31 AM) *jsdelfino:* ... if we introduce an @SDOHelper annotation
(09:50:42 AM) *jsdelfino:* to inject the correct typeHelper into a 
component implementation
(09:50:48 AM) *jboynes:* type helper scope is tied to TCCL and 
composites aren't
(09:51:15 AM) *jsdelfino:* TypeHelper.INSTANCE is tied to TCCL
(09:51:30 AM) *jsdelfino:* what about a new TypeHelperImpl()?
(09:52:08 AM) *jboynes:* with support for the annotation
(09:52:09 AM) *fbudinsky:* SDOUtil.createTypeHelper() is what you want
(09:52:28 AM) *jsdelfino:* frank, yes, exactly
(09:52:32 AM) *jboynes:* and SDOUtil.createTypeHelper(TypeHelper parent)
(09:52:43 AM) *fbudinsky:* you guys should never use .INSTANCE for any 
helper ... make it a build verification test :-)
(09:52:59 AM) *jsdelfino:* agreed
(09:53:14 AM) *jboynes:* it's not just us - we need make it easy for 
users too
(09:53:22 AM) *fbudinsky:* there are SDOUtil create methods for every 
kind of helper ... if you need more arguments just let me know
(09:53:37 AM)* ant_away left the room (quit: Read error: 104 (Connection 
reset by peer)).*
(09:54:10 AM) *jboynes:* so, trivially now we can add <import.sdo 
factory="..."/>
(09:54:17 AM) *jsdelfino:* I was not thinking that app developers would 
use SDOUtil.createTypeHelper()... if they did that they would have to 
configure the TypeHelper themselves
(09:54:37 AM) *jboynes:* they should never see it
(09:54:53 AM) *jboynes:* we should add a security check that prevents it
(09:54:55 AM) *jsdelfino:* what about we add an @SDOHelper annotation, 
which injects the configured typeHelper for the current composite
(09:55:12 AM) *jboynes:* :-)
(09:55:26 AM) *jboynes:* we need to add that as well
(09:55:44 AM) *fbudinsky:* that's why i thought you would want the 
config model ... the app declares all it's models in the format 
described in my note ... you guys instantiate the typehelper ... 
register his models ... and then pass him the typehelper
(09:56:06 AM) *jsdelfino:* yes, makes sense to me
(09:57:13 AM) *jboynes:* it's the "register his models" bit that I am 
still worriedabout
(09:58:04 AM) *jboynes:* it seems to me that he now needs to write two 
things: the sca file and a separate sdo config file
(09:58:45 AM) *jsdelfino:* frank, would you be ok to define the 
@SDOHelper annotation in a new SDO sub-project? or do you guys think 
that we can define it in one of the SCA projects now?
(09:58:56 AM) *jboynes:* lets do it in sca
(09:59:00 AM) *jsdelfino:* +1
(09:59:12 AM) *jboynes:* at some point sdo will need to move up to 1.5 
and we can move it there then
(09:59:18 AM) *fbudinsky:* sca seems best for now anyway
(09:59:27 AM) *jsdelfino:* ok, package name?
(09:59:55 AM) *jboynes:* fbudinsky, are we looking at two files?
(10:00:18 AM) *fbudinsky:* you could embed the sdo config model in the 
scdl file instead of having it in aseparate file
(10:01:01 AM) *jboynes:* o.a.t.binding.sdo
(10:01:05 AM) *fbudinsky:* you have wildcards in the scdl model so you 
just need to use the global element i added to the schema
(10:01:20 AM) *jsdelfino:* binding?
(10:01:23 AM) *jsdelfino:* databinding?
(10:01:43 AM) *jsdelfino:* IMO binding is confusing
(10:01:53 AM) *fbudinsky:* for the config model (sdoMetaDataGroup)
(10:01:54 AM) *jboynes:* yes/no - the wildcards are in the wrong place
(10:02:02 AM) *jboynes:* we would want to import the SDO types before 
using any SDOs
(10:02:35 AM) *jboynes:* e.g. to load complex property values
(10:03:28 AM) *jboynes:* otoh we could use something like an sdoFactory 
attribute on the property value
(10:04:08 AM) *jboynes:* <properties><v:foo 
sdoFactory="com.foo.FooFactory"><foo>...
(10:06:20 AM) *jboynes:* I think databinding is a bit long winded but 
otherwise ok
(10:06:35 AM) *jsdelfino:* why would an app developer need to specify 
the factory here? if he already has an <sdo.import> specifying factory 
at the top of the scdl file?
(10:06:57 AM) *jboynes:* if he didn't
(10:07:08 AM) *jboynes:* and this may also be local as in the app may 
not need to define the property type
(10:07:50 AM) *jboynes:* as in, I may use sdo to load a Bar propery but 
not have Bar types in my application type helper
(10:09:26 AM) *jboynes:* make sense?
(10:09:35 AM)* jmarino left the room (quit: ).*
(10:11:00 AM) *jsdelfino:* not sure, I find this very confusing
(10:11:14 AM) *jsdelfino:* you'd be able to get this SDO injected into 
your property
(10:11:29 AM) *jsdelfino:* but dataFactory.create(theSDOclass.class) 
would fail?
(10:11:35 AM) *jboynes:* yes
(10:11:51 AM) *jsdelfino:* but dataFactory.create(theSDO.getType()) 
would work?
(10:12:00 AM) *jboynes:* no, it may fail
(10:12:10 AM) *jsdelfino:* may?
(10:12:26 AM) *jboynes:* if the two type systems are separate
(10:12:49 AM) *jsdelfino:* the two type systems?
(10:13:13 AM) *jboynes:* the one for the app and the one the container 
uses to instantiate the complex property
(10:13:58 AM) *jboynes:* prop is of type Bar and all the app sees is the 
injection of a Bar
(10:14:31 AM) *jsdelfino:* having trouble imagining a concrete use case 
for this, what concrete use case were you thinking about?
(10:14:55 AM) *jboynes:* it should not know how the container 
instantiates Bar - it may be SDO, it may be JAXB, it may be hard coded
(10:16:34 AM) *jboynes:* so it may send/recieve Foo's as parametes but 
Foo may be in a different type system than Bar
(10:16:39 AM) *jsdelfino:* who is "it"? the component implementation? 
sorry I'm lost
(10:16:44 AM) *jboynes:* yes
(10:16:56 AM) *jboynes:* the user's code
(10:17:40 AM) *jboynes:* Bar's are created by the container, Foo's are 
created by the user code, and never shall they be confused :-)
(10:18:01 AM) *jboynes:* otherwise you'd be fubared
(10:18:18 AM) ****jboynes* runs and ducks for cover
(10:19:14 AM) *jsdelfino:* if a Web Service binding receives an XML 
instance of the type in question, which one would it create?
(10:20:09 AM) *jboynes:* Foo
(10:20:18 AM) *jboynes:* if it got a Bar things would be fubar
(10:21:04 AM) *jsdelfino:* so user's code would create Foo, a web 
service binding would pass Foo, but an injected property would be a Bar
(10:21:10 AM) *jboynes:* if the app needs Bar's (e.g. as args) then they 
would need to be in the app's type system
(10:21:15 AM) *jsdelfino:* still can't make sense of this scenario... sorry
(10:21:16 AM) *jboynes:* yes
(10:22:03 AM) *jsdelfino:* can we summarize this discussion?
(10:22:27 AM) *jboynes:* basically property values and parameters are 
different things
(10:23:04 AM) *jboynes:* and there should be no need to have them mixed 
in the same type system (unless you want them)
(10:23:47 AM) *jsdelfino:* I find this very confusing, specially if 
you're going to pass property values as parameters, I think I'd need to 
see this in action in a real sample / scenario to understand the value 
of supporting this
(10:24:17 AM) *jsdelfino:* but let's not get hung up on the fact that 
I'm confused by this
(10:24:19 AM) *jboynes:* if you are passing property values as 
parameters then they are application types
(10:24:33 AM) *jsdelfino:* if others understand they it's fine
(10:24:55 AM) *jsdelfino:* can we summarize the <sdo.import> story?
(10:25:32 AM) *jsdelfino:* my understanding is that we're going to have 
a new <sdo.import> element, is that correct?
(10:25:33 AM) *jboynes:* sdo.import or import.sdo ?
(10:25:40 AM) *jboynes:* we had import.wsdl
(10:25:47 AM) *jsdelfino:* ok, import.sdo
(10:26:07 AM) *jboynes:* ok, yes we will have that
(10:26:11 AM) *jsdelfino:* <import.sdo> can take an xsd file?
(10:26:15 AM) *jsdelfino:* yes I guess?
(10:26:25 AM) *jboynes:* yes
(10:26:33 AM) *jboynes:* and we call XSDHelper
(10:26:38 AM) *jsdelfino:* ok, <import.sdo> can take a wsdl file? yes?
(10:27:03 AM) *jboynes:* is it any different
(10:27:04 AM) *jboynes:* ?
(10:27:11 AM) *jboynes:* yes
(10:27:14 AM) *jboynes:* never mind
(10:27:34 AM) *jboynes:* <import.sdo schemaLocation="foo.xsd"/>
(10:27:44 AM) *jboynes:* <import.sdo wsdlLocation="foo.wsdl"/>
(10:28:00 AM) *jsdelfino:* question for frank, if a wsdl inlines 10 
xsds, are the 10 xsd schemas loaded and "defined"?
(10:28:02 AM) *jboynes:* <import.sdo factory="com.foo.FooFactory"/>
(10:28:43 AM) *jsdelfino:* ok, while frank thinks about it, next is 
we're going to have an @SDOHelper, yes?
(10:28:47 AM) *jboynes:* jsdelfino, let's assume so (just like I assume 
imported schemas are defined)
(10:28:54 AM) *jboynes:* hand on
(10:28:59 AM) *jboynes:* hang on ...
(10:29:01 AM) *jboynes:* also
(10:29:25 AM) *jsdelfino:* are imported schemas defined? or just 
included ones?
(10:29:35 AM) *jsdelfino:* 2 questions for frank in the pipe now :)
(10:29:50 AM) *jboynes:* <import.sdo sdoMetaData="foo.sdoMetaData"/>
(10:30:20 AM) *jboynes:* so, four forms of <import.sdo>
(10:30:26 AM) *jsdelfino:* ok, works for me
(10:30:39 AM) *jboynes:* do we want to use attributes or nested elements?
(10:30:48 AM) *jboynes:* I say allow both
(10:31:12 AM) *jboynes:* nah
(10:31:14 AM) *jboynes:* just repeat the import
(10:31:40 AM) *jsdelfino:* I'd like to be consistent with other imports, 
IMHO more choices doesn't always mean simpler... next: @SDOHelper 
injects a composite scoped SDO helper
(10:31:54 AM) *jboynes:* what is consistent?
(10:32:37 AM) *jsdelfino:* the SCDL import.wsdl? import in WSDL itself? 
import in XML schema?
(10:33:47 AM) *jboynes:* let's just do it and see what folk think
(10:33:53 AM) *jsdelfino:* I have to leave the chat in 2 mins, can we 
say we support attributes? and leave the "support elements also" open 
for further discussion if you want?
(10:34:01 AM) *jsdelfino:* do what sorry?
(10:34:09 AM) *jboynes:* attributes
(10:34:13 AM) *jsdelfino:* k
(10:34:26 AM) *jsdelfino:* are u ok with @SDOHelper?
(10:34:30 AM) *jboynes:* yes
(10:35:14 AM) *jsdelfino:* ok, I'm not sure about the visibility/scoping 
rules for metadata with nested composites...
(10:35:27 AM) *jsdelfino:* in other words do we have 
TypeHelper(parentHelper) or not
(10:35:39 AM) *jsdelfino:* but perhaps we can start with the simple case
(10:35:46 AM) *fbudinsky:* i'm back ... frankb qustion #1 : all the 
inlined schemas in a wsdl are defined when you call define with a .wsdl file
(10:35:46 AM) *jsdelfino:* one helper per composite?
(10:35:57 AM) *jsdelfino:* ok good
(10:35:59 AM) *jboynes:* we will need it to allow typehelpers to 
delegate to the default (INSTANCE)
(10:36:34 AM) *jsdelfino:* frankb, don't the helpers delegate to the 
default INSTANCE by default?
(10:36:51 AM) *jsdelfino:* with the current implementation?
(10:37:14 AM) *fbudinsky:* frankb question #2 ... only included things 
are defined ... imports are assumed to be defined separatedly and 
referenced ... there may be some improvements to this in the future
(10:37:50 AM) *jsdelfino:* ok, that's what I thought, makes sense to me 
for now
(10:38:04 AM)* Simon1 left the room (quit: "Bye").*
(10:38:18 AM) *jsdelfino:* ok I think we have a plan?
(10:38:30 AM) *fbudinsky:* i tried to keep the default INSTANCE out of 
the picture ... whatever helper you have ... should normally be created 
with SDOUtil create calls which are parameterized with a TypeHelper
(10:38:55 AM) *jsdelfino:* do u guys want me to create the JIRA issues 
for the various work items resulting from this discussion?
(10:39:10 AM) *jboynes:* sure
(10:39:15 AM) *jsdelfino:* cool
(10:39:41 AM) *jsdelfino:* since this was our regularly IRC discussion 
I'll post the log to the dev list as well
(10:40:11 AM) *jboynes:* we didn't get to distro's :)
(10:40:46 AM) *jsdelfino:* I know, but not many people were active this 
monring, this should be a group discussion. I'd like to set up another 
IRC with everybody soon, tomorrow maybe
(10:41:07 AM) *jboynes:* it's a bad week for some of us
(10:41:07 AM) *jsdelfino:* does tomorrow work for most people?
(10:41:36 AM) *jboynes:* the spec meetings run all day
(10:42:01 AM) *jsdelfino:* yes I know, but we need to get things figured 
out so that the people not in the spec meetings can make progress while 
you guys are discussing the spec...
(10:42:39 AM) *jsdelfino:* I'll send a proposal for another chat 
tomorrow same time, if people want to propose alternate times, let's 
handle that on the dev list
(10:42:48 AM) *jboynes:* yeah - the distro thing would be good to sort out
(10:42:56 AM) *jsdelfino:* agreed, we made good progress on the SDO 
metadata story today
(10:42:57 AM)* robbins left the room (quit: Connection timed out).*
(10:43:02 AM) *jsdelfino:* thanks all
(10:43:10 AM) *jsdelfino:* ttyl

-- 
Jean-Sebastien