Hi Mary. We had to make this decision about 12 months ago and decided to use #2 as well as encoding the equivalent information into the schemaLocation attribute. This was driven mainly by a reading of section 4.3.2 of the Schema structures document (as it was then), which implied that toolsets might end up using the schemaLocation OR the namespace to locate the schema. We figured we could always freeze one or the other depending on how the best practices evolved. As it turned out, I'm glad we did include the version in the schemaLocation as most of the tools to date have used this as the mechanism to pick up the relavent schema. Regards Michael <OffTopic> I realise the best practices are about schemas but IMHO, the issue of versioning the XML content needs to be considered as well, for a versioning scheme to be effective. Naturally, this is domain specific As an example, we also added a version attribute on each transaction, within our transaction framework. The driver here was that the transaction could become disconnected from the document in which it was delivered, as multiple transactions directed to multiple backend systems can be delivered in a single document. By attaching a version attribute to each transaction, the backend processing can provide the appropriate logic switch for different versions, without knowledge of the schema version under which the transaction was delivered. This version attribute reflects the schema version at which the transaction structure last changed. This allows the schema version to progress without needing to touch the backend code to track these changes, except in the case where the application logic is affected. </OffTopic> Mary Pulvermacher To: xml-dev <email@example.com> <pulver@mitre cc: firstname.lastname@example.org .org> Subject: XML Schemas: Best Practices ? Versioning 06/09/2001 03:50 AM Hello everyone- Roger Costello has asked me to initiate this Best Practice topic. The results of this discussion will be posted, along with the other Best Practices, on the Best Practice Homepage ( http://www.xfront.com/BestPracticesHomepage.html). Topic: What is the Best Practice for versioning XML schemas? Is it better to version a schema by: 1. Changing the (internal) schema version attribute, 2. Changing the schema's targetNamespace, 3. Changing the name of the schema, or 4. Changing the location of the schema? 1. CHANGING THE SCHEMA VERSION ATTRIBUTE In this approach one would simply change the number in the optional version attribute at the start of the XML schema. For example, in the code below one could change version="1.0" to version="1.1" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> This approach is very easy to use. Also, no change is needed to the instance document if it is not affected by the change in the schema. However, the validator ignores this field. Therefore, I regard the version attribute as a cue to the human (especially if their schema doesn't validate) rather than an enforceable constraint. This approach could be used in conjunction with any of the other approaches. 2. CHANGING THE SCHEMA'S TARGET NAMESPACE In this approach, the 'targetNamespace' attribute at the start of the schema could be changed to designate that a new version of the schema exists. One way to do this is to include a schema version number in the designation of the target namespace as shown in the example below. <xs:schema xmlns="http://www.addressGlobalsV1.0" targetNamespace="http://www.addressGlobalsV1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> Then one could update the version number in the target namespace designation with each change to the schema. With this approach, instance documents will not validate until they are changed to designate the new targetNamepsace. A disadvantage of this approach is that it forces all instance documents to change, even if the change to the schema would not impact that instance. Also, any schemas that 'include' this schema would have to change because the target namespace of the included components must be the same as the target namespace of the including schema. 3. CHANGING THE NAME OF THE SCHEMA This approach changes the file name of the schema. This should sound familiar since most people develop conventions for naming their files so that they know which version is the most current (e.g., append version number or date to end of file name). Since instance documents give the name and location of the associated schema, the instance documents will not validate until they are changed to designate the new schema file name. As with option 2, one disadvantage of this approach is that it forces all instance documents to change, even if the change to the schema would not impact that instance. Also, any schemas that import the modified schema would have to change since the import statement provides the name and location of the imported schema. This approach seems most powerful when used in conjunction with approaches 1 and 4. For example, one could set up a convention whereby the latest version of a particular schema is always available in a specific location under a specific filename. The version number inside the schema (and any annotations) could provide details on version number and a change history. Old versions of the schema may still be made available in an archive. This approach seems most feasible to me for implementing XML schema registries. With this approach, one always knows where to get the latest version but small changes to the schema would not impact any schemas that 'inherit' (include or import) the schema. This mimics an approach taken by the W3C on the XML Schema specification. For example, the latest version of the "XML Schema Specification Part 0: Primer" is always called "xmlschema-0". Previous versions are available but the file names include a date to distinguish it from the latest version. 4. CHANGING THE LOCATION OF THE SCHEMA The last approach is changing the location of schema. This is very similar to changing the schema file name and really doesn't seem to make much sense when used alone. As mentioned above, a versioning approach that combines this approach with options 1 and 3 seems powerful. ************ Your Opinion? ************ What is your opinion on the advantages and disadvantages of the respective approaches? Which approach do you think works best? Are there other options I have missed? Do you have a favorite way of handling schema versioning? If so, why did you choose this approach? Please send your comments. I'd love to hear from you. Thanks in advance for your help. Mary Pulvermacher -- Mary K. Pulvermacher The MITRE Corporation email@example.com (719) 572-8241 ---------------------------------------------------
I’ve done some more tuning over the past couple of days. I’ve also done some reading about how to make OpenCL perform better on ARM Mali. In this post I’m going to retrace some of my steps, share what my tests looks like, share what some of my OpenCL looks like, share current performance numbers and last discuss next steps.
This is in many ways still a prototype / proof of concept. My early goals are to get a very good sense what the possible performance of an OpenCL accelerated SQLite would be for the general case. From this prototype I want to be able to iterate to complete implementation.
Performance Testing the Prototype
I’m comparing the c apis that SQLite provides as well as my own API that I’ve developed. My API works with the same data structures and is compiled with the SQLite source code. I’m…
View original post 1,973 more words
Build an automated testing, continuous integration, and continuous deployment system, using Maven, Hudson, WebLogic Server, JUnit, and NetBeans. Developed with Oracle’s Pre-Built Enterprise Java Development VM. Download the complete source code from Dropbox and on GitHub.
In this post, we will build a basic automated testing, continuous integration, and continuous deployment system, using Oracle’s Pre-Built Enterprise Java Development VM. The primary goal of the system is to automatically compile, test, and deploy a simple Java EE web application to a test environment. As this post will demonstrate, the key to a successful system is not a single application, but the effective integration of all the system’s applications into a well-coordinated and consistent workflow.
Building system such as this can be complex and time-consuming. However, Oracle’s Pre-Built Enterprise Java Development VM already has all the components we need. The Oracle VM includes NetBeans IDE for development, Apache…
View original post 3,023 more words
Tweet I recently started to build a small project in JDeveloper 12c to learn how to make use of Custom Activities in an Adaptive Case Management project. The results of this project will be posted in my next blog. When […]
If you do not wish to use the JMS Reporting Provider that is provided with your Oracle Service Bus installation, you can untarget it and create your own reporting provider using the Reporting Service Provider Interface (SPI). If you configure your own reporting provider for messages, no information is displayed in the Oracle Service Bus Administration Console. You must to create your own user interface.
Since the report action places a java object on an internal JMS queue named wli.reporting.jmsprovider.queue we can play around with it from their.
Initially we wanted to discover what information this Java Object contained. So I’ve created a simple EJB project as an example named it CustomOsbReportHandler.
This project was build with WLS/OSB 220.127.116.11 and the project uses…
View original post 400 more words
A Slight Briefing
Oracle Business Rules is a high performance and lightweight business rules product that is part of the Oracle Fusion Middleware Suite that can be used in both SOA and BPM suite.
To have a business process more agile and coherent with the changing demands of Business, Oracle Business rules is a must for any design. Also it should act as a central component where all process rules are located.
With OBR 11g one added advantage of business rules is that they can be exposed as any other web service. This makes it an instant hit as it becomes hot pluggable.
Here in this example blog i would show how to create a complex rule in JDeveloper and test it out through multiple ways. This is intended to be a zero lecture hands on so i would skip the talk.
- SOA Suite 11gPS2 or PS3 is installed…
View original post 1,314 more words