Initializing of readonly properties in SDO
How can I initialize SDO readonly property using SDO API or Tuscany Implementation? I'm trying to make my own DAS from specific source and I need to initially set readonly property. It's not a default value, it's value that I can't change later by SDO API. I thought I could change it before I started logging in DataGraph, but I couldn't because of the exception: The feature 'ID' is not a valid changeable feature. Thanks, Stepan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Making the SDO SCA schemas available via internet
Hi, I like to keep my (eclispe) workspaces free of red x's (errors) and make use of content assistance where ever possible. As a result I keep copying the various SDO and SCA schema files to different projects and workspaces. An alternative I've tried is to directly reference the schemas location in subversion, eg http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo-api/src/main/resources/xml/sdoModel.xsd However, this means that when schemas change existing XML files could become invalid. For example, SDO 3's schema could introduce a change that is not backwards compatible. Is there any desire to fix this by hosting a copy (or linking to a specific subversion revision) off the main tuscany site url, for example: http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd. Alternatively does (or should) OSOA.org host them somewhere (I can't find any links). Either way I think it would be a good idea to have SDO and SCA schemas available directly off the internet... WDYT? Cheers, Dan
Re: Making the SDO SCA schemas available via internet
On 08/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, I like to keep my (eclispe) workspaces free of red x's (errors) and make use of content assistance where ever possible. As a result I keep copying the various SDO and SCA schema files to different projects and workspaces. An alternative I've tried is to directly reference the schemas location in subversion, eg http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo-api/src/main/resources/xml/sdoModel.xsd However, this means that when schemas change existing XML files could become invalid. For example, SDO 3's schema could introduce a change that is not backwards compatible. Is there any desire to fix this by hosting a copy (or linking to a specific subversion revision) off the main tuscany site url, for example: http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd. Alternatively does (or should) OSOA.org host them somewhere (I can't find any links). Either way I think it would be a good idea to have SDO and SCA schemas available directly off the internet... WDYT? Cheers, Dan I think ultimately they should be available from OSOA site. Can you just link into the svn src tree in the tag for the release you are using? Cheers, -- Pete
Re: Making the SDO SCA schemas available via internet
Do'oh what a muppet (I am)... didn't think of that, though the url is not the most memorable, it fixes my immediate concern... thanks Pete :) Anyone from the OSOA collab around who can raise this? Dan On 08/01/07, Pete Robbins [EMAIL PROTECTED] wrote: On 08/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, I like to keep my (eclispe) workspaces free of red x's (errors) and make use of content assistance where ever possible. As a result I keep copying the various SDO and SCA schema files to different projects and workspaces. An alternative I've tried is to directly reference the schemas location in subversion, eg http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo-api/src/main/resources/xml/sdoModel.xsd However, this means that when schemas change existing XML files could become invalid. For example, SDO 3's schema could introduce a change that is not backwards compatible. Is there any desire to fix this by hosting a copy (or linking to a specific subversion revision) off the main tuscany site url, for example: http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd. Alternatively does (or should) OSOA.org host them somewhere (I can't find any links). Either way I think it would be a good idea to have SDO and SCA schemas available directly off the internet... WDYT? Cheers, Dan I think ultimately they should be available from OSOA site. Can you just link into the svn src tree in the tag for the release you are using? Cheers, -- Pete
Re: Making the SDO SCA schemas available via internet
Hi Dan, I've heard that a more general problem is that the namespace URIs that SDO uses for its standard types: commonj.sdo commonj.sdo/xml commonj.sdo/java are problematic since they are not absolute URIs and according to some WS spec are not really valid, so some web servers completely ignore them. If that is true, then SDO is going to need to make a change to use proper absolute URIs for these namespaces. For example: http://www.osoa.org/2007/sdo; http://www.osoa.org/2007/sdo/xml; http://www.osoa.org/2007/sdo/java; Then you won't need to include a schemaLocation, since the imported namespaces themselves will be available on the internet. I guess the first step is to open an issue with the SDO specification and see what results. Frank Dan Murphy [EMAIL PROTECTED] wrote on 01/08/2007 10:40:41 AM: Do'oh what a muppet (I am)... didn't think of that, though the url is not the most memorable, it fixes my immediate concern... thanks Pete :) Anyone from the OSOA collab around who can raise this? Dan On 08/01/07, Pete Robbins [EMAIL PROTECTED] wrote: On 08/01/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi, I like to keep my (eclispe) workspaces free of red x's (errors) and make use of content assistance where ever possible. As a result I keep copying the various SDO and SCA schema files to different projects and workspaces. An alternative I've tried is to directly reference the schemas location in subversion, eg http://svn.apache.org/repos/asf/incubator/tuscany/java/spec/sdo- api/src/main/resources/xml/sdoModel.xsd However, this means that when schemas change existing XML files could become invalid. For example, SDO 3's schema could introduce a change that is not backwards compatible. Is there any desire to fix this by hosting a copy (or linking to a specific subversion revision) off the main tuscany site url, for example: http://incubator.apache.org/tuscany/schemas/sdo/2.1.0/sdoModel.xsd. Alternatively does (or should) OSOA.org host them somewhere (I can't find any links). Either way I think it would be a good idea to have SDO and SCA schemas available directly off the internet... WDYT? Cheers, Dan I think ultimately they should be available from OSOA site. Can you just link into the svn src tree in the tag for the release you are using? Cheers, -- Pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initializing of readonly properties in SDO
Hi Stepan I was chatting with Brent, that tried before using readony properties in our Tuscany DAS implementation and wasn't able to have success doing that. You will need some help from the SDO guys, sorry. May I ask you what datasource you are trying to handle with your own DAS ? -- Luciano Resende http://people.apache.org/~lresende On 1/8/07, Dan Murphy [EMAIL PROTECTED] wrote: Hi Stephan, I think this is a very interesting point. The spec says that setting readonly properties is the responsibility of the DAS, without saying how the DAS should do this ! One way I have got around this was to generate static classes and create my own setter for read only properties, but this is only any good for static SDOs. Perhaps the DAS chaps can let is know how they do it... I suspect you'll need to cast and dip into the actual DynamicDataObjectImpl class On 08/01/07, Stepan Ilchenko [EMAIL PROTECTED] wrote: How can I initialize SDO readonly property using SDO API or Tuscany Implementation? I'm trying to make my own DAS from specific source and I need to initially set readonly property. It's not a default value, it's value that I can't change later by SDO API. I thought I could change it before I started logging in DataGraph, but I couldn't because of the exception: The feature 'ID' is not a valid changeable feature. Thanks, Stepan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
