Feed aggregator

Develop with choice...

Branislav Nemec - Sun, 2011-02-13 08:57
JDeveloper is really a tool you can be very productive with and not only develop but also deploy with choice. Like the splash window of JDeveloper (some developer guys find it stodgy) outlines: Develop with choice is probably wish of most of Java developers today.

Problem with deploying ADF 11g application to production Web Logic server 10.3

Branislav Nemec - Sun, 2011-02-13 08:55
Seems like since development stage with ADF 11g is smooth more or less with JDeveloper 11g, there are many not nice bugs when you try to deploy your application to Oracle WLS 10.3.0 After two days fighting with deployment of my application to the stand alone Oracle Web Logic server 10.3.0 I finally made it work. Since it is full of pitfalls (Oracle, Oracle!!!) I decided to share the tricks with you.

ADF Faces 11g Rich Client and Oracle Maps - how to integrate it without use of GeoMap ADF Faces component

Branislav Nemec - Sun, 2011-02-13 08:54
With the new ADF Faces components 11g Rich Client we can very easily include geographical maps into a Fusion Application via out-of-the-box ready JSF components. But we are faced the problem if we are not satisfied with UI of the component or its behaviour. In this case we can integrate Oracle Maps into ADF Faces application like in common HTML page.

Open Account AP Balance Listing

Krishanu Bose - Fri, 2011-02-11 01:19
As per Metalink Note 604739.1, the AP Trial Balance has been replaced by the Open Account AP Balance Listing in R12. This report is a variation on the more general Open Account Balances Listing, and shows basically the outstanding amount (liability) for all open AP invoices. The balance should match your AP liability account(s) in General Ledger. Users can create their own layout and publish their custom reports using Oracle XML Publisher.

Energy Firms Targetted for Sensitive Documents

Simon Thorpe - Thu, 2011-02-10 18:54

oilwell.jpgNumerous multinational energy companies have been targeted by hackers who have been focusing on financial documents related to oil and gas field exploration, bidding contracts, and drilling rights, as well as proprietary industrial process documents, according to a new McAfee report.

"It ... speaks to quite a sad state of our critical infrastructure security. These were not sophisticated attacks ... yet they were very successful in achieving their goals," said Dmitri Alperovitch, McAfee's vice president for threat research.

Apparently, the attacks can be traced back over several years, creating a sustained security compromise that has provided access to highly sensitive information that is of huge financial value to competitors.

The value of IRM as an additional layer of protection is clear. Whether your infrastructure security is in a sad state or is state of the art, breaches are always a possibility - and in any case, a lot of sensitive information is shared with third parties whose infrastructure security might not be as good as yours. IRM protects the individual information assets directly so that, even if infrastructure security is compromised, your critical information is enrypted and trackable and only accessible to authenticated, authorised, audited users.

The full McAfee report is available here.

 

 

Oracle VM

Edward Whalen - Thu, 2011-02-10 09:14
I just wanted to let you know that I am finalizing the last bits of my latest book; Oracle VM Implementation and Administration Guide. You can use Oracle VM to host both Windows and Linux guest machines. The book (according to Amazon) should be out in early August. Enjoy. Ed W.

Enabling the 11gR2 Grid Infrastructure on Windows

Edward Whalen - Thu, 2011-02-10 09:11
I was recently asked if Oracle 10.2.0.5 was available for CRS for Windows. At first I started looking up to see if 10.2.0.5 had CRS components, and then I decided to ask about the end goal. It turns out that the final goal was to install a new RAC cluster with the 10.2.0.5 database.

With this new information in mind I immediately recommended that the 11gR2 Grid Infrastructure be installed. This provides the most stable and robust clusterware and ASM software and at the same time extending the lifetime of these components before they need to be upgraded.

In addition, by using the 11gR2 Grid Infrastructure both 10g and 11g RAC databases can be created. This will allow you to create an 11gR2 database for testing. Since the architecture of RAC has changed slightly in 11gR2 it is best to move to this structure for any new installations, even if a 10g database is the end result.

So, what has changed? In Oracle 10g and 11gR1 there were three separate components and/or Oracle homes that were used for RAC; the CRS, the ASM home and the database home. In 11gR2 the clusterware and ASM homes are combined into the Grid Infrastructure and have one home. In addition, the confusion as to which listener to use is clarified by having the cluster, ASM and master listener run out of the Grid Infrastructure. Now, instead of three Oracle homes, there are two; Grid Infrastructure and database.

So, if you are planning any new RAC installations on Windows, do yourself a favor and use the 11gR2 Grid Infrastructure, even if you are installing a 10g database.

From Oracle Newbie to Oracle ACE...

Lisa Dobson - Wed, 2011-02-09 02:25
When I started this blog over 5 years ago, I never imagined that it would take me on a journey from an Oracle Newbie, to a Director of UKOUG and onto an Oracle ACE (even if I did go via some strange evenings in some strange pubs in Birmingham and a rather dodgy Panto!)All I can say is that it has been a heck of a ride!I’ve enjoyed every minute of it and for me, the best part of it has been the Lisahttp://www.blogger.com/profile/16434297444320005874noreply@blogger.com6

JD Edwards Partner Summit

Andrews Consulting - Thu, 2011-02-03 10:12
 Over 300 people attended the recent JD Edwards Partner Summit in Denver – a clear indication that the product line remains alive and well.  Most were from the US with a sprinkling of partners from each of the other regions around the world.  Everyone that I talked to echoed the same story – after a […]
Categories: APPS Blogs

Virtual Moving Day!

Digital Eagle - Sun, 2011-01-30 19:53

Well, I finally decided to do it!  I got my own website.  So, now comes the challenging part of moving it all to the new site.

So, please update your feeds and bookmarks to:

http://psst0101.digitaleagle.net/

And, if you have any suggestions on how I can make it better, please comment.  I apologize for the inconvenience.


Oracle Linux 5.6 is out

Sergio's Blog - Fri, 2011-01-28 06:14

I wrote a quick summary of the Oracle Linux 5.6 release over on our Linux blog. For what it's worth, 5.6 is on public-yum.oracle.com as well.

Categories: DBA Blogs

Everybody needs a spare database

alt.oracle - Sun, 2011-01-23 17:29

I've gotten a little preachy in this blog lately, so I thought this time I'd give you something useful. Have you ever wished you had a quicky little set of database tables so you could do some generally wacky stuff that would likely get you fired if you did it on your production database? I thought so. In the past, the only way to do something like this was to build another database somewhere. Of course, where to put it? Some of us weirdos have machines at home where we build databases, do virtual machines or stuff like that. Guilty. But not everyone wants to tie up their home machine with the multi-gigabyte behemoth that Oracle 11g has become. Well, have I got a deal for you.

Oracle provides a nifty little free service to show off their Oracle Application Express product (APEX), which I'm not sure has been as popular as they'd like it to be. You can register at their site and get your own little workspace that will allow you to play around with Oracle a little.

Here's how it works.

  • Go to http://apex.oracle.com and click the link to "Sign Up"
  • Click through the "next" buttons, giving Oracle your name and email address. Give them a real one since they'll send the verification link to it.
  • Provide a name for your workspace and a schema name for your database objects
  • Next you have to give a reason for requesting an account. Now, I don't know if anyone actually reads these or not, but you'd probably be better off if you didn't put something like "That dork from alt.oracle said it would be cool." Try "Evaluation purposes" instead.
  • Next, you type in your little verification thing with the goofy letters and click "Submit Request"
  • After a bit, you'll hopefully get an email back saying "click this link to verify, etc".
  • Lastly, you'll get another email with your login.

Then you can login and poke around. Truthfully, you can do a lot of stuff on your new personal Apex. I'm not super familiar with it yet, but it looks like you can...

  • Create your own tables, indexes, constraints, sequences, etc
  • Run SQL statements and scripts
  • Build PL/SQL objects
  • Build your own webby-type applications with the GUI "Application Builder"

I'm not sure yet if you can build web apps that you and others could access from a browser without going through the whole Apex frontend, but if so, that would be uber-cool. One word of warning however. FOR THE LOVE OF ALL THAT IS HOLY, DON'T PUT ANY REAL DATA IN THIS CRAZY THING! I have no idea as to how secure it is – it's only for evaluation purposes, so DON'T DO IT.

You can't do a lot of administration-type stuff with your own personal Apex. If you're looking to mess with parameter files and flash recovery areas, it's time to bust out a virtual machine. But it is nice to have a place where you could try some SQL stuff without fear of a pink-slip visit from HR. So go get your account and do some crazy, webby SQL stuff. And, finally, FOR THE LOVE OF ALL THAT IS HOLY, DON'T PUT ANY REAL DATA IN THIS CRAZY THING!
Categories: DBA Blogs

Maintaining One Code Base with Possibly Conflicting Custom Features

Kenneth Downs - Fri, 2011-01-21 21:21

Today's essay deals with the tricky issue of custom features for individual customers who are running instances of your software.

The question comes by way of a regular reader who prefers to remain anonymous, but asks this:

... I work on a large (to me, anyway) application that serves as a client database, ticket system, time-tracking, billing, asset-tracking system. We have some customers using their own instances of the software. Often, those customers want additional fields put in different places (e.g., a priority column on tickets). This results in having multiple branches to account for versions with slight changes in code and in the database. This makes things painful and time-consuming in the long run: applying commits from master to the other branches requires testing on every branch; same with database migrate scripts, which frequently have to be modified.

Is there an easier way? I have thought about the possibility of making things "optional" in the database, such as a column on a table, and hiding its existence in the code when it's not "enabled." This would have the benefit of a single code set and a single database schema, but I think it might lead to more dependence on the code and less on the database -- for example, it might mean constraints and keys couldn't be used in certain cases.

Restating the Question

Our reader asks, is it better to have different code branches or to try to keep a lot of potentially conflicting and optional items mixed in together?

Well, the wisdom of the ages is to maintain a single code branch, including the database schema. I tried exactly once, very early in my career, to fork my own code, and gave up almost within days. When I went to work in larger shops I always arrived in a situation where the decision had already been made to maintain a single branch. Funny thing, since most programmers cannot agree on the color of the sky when they're staring out the window, this is the only decision I have ever seen maintained with absolute unanimity no matter how many difficulties came out of it.

There is some simple arithmetic as to why this is so. If you have single feature for a customer that is giving you a headache, and you fork the code, you now have to update both code branches for every change plus regression test them both, including the feature that caused the headache. But if you keep them combined you only have the one headache feature to deal with. That's why people keep them together.

Two Steps

Making custom features work smoothly is a two-step process. The first step is arguably more difficult than the second, but the second step is absolutely crucial if you have business logic tied to the feature.

Most programmers when confronted with this situation will attempt to make various features optional. I consider this to be a mistake because it complicates code, especially when we get to step 2. By far the better solution is to make features ignorable by anybody who does not want them.

The wonderful thing about ingorable features is they tend to eliminate the problems with apparently conflicting features. If you can rig the features so anybody can use either or both, you've eliminated the conflict.

Step 1: The Schema

As mentioned above, the first step is arguably more difficult than the second, because it may involve casting requirements differently than they are presented.

For example, our reader asks about a priority column on tickets, asked for by only one customer. This may seem like a conflict because nobody else wants it, but we can dissolve the conflict when we make the feature ignorable. The first step involves doing this at the database or schema level.

But first we should mention that the UI is easy, we might have a control panel where we can make fields invisible. Or maybe our users just ignore the fields they are not interested in. Either way works.

The problem is in the database. If the values for priority come from a lookup table, which they should, then we have a foreign key, and we have a problem if we try to ignore it:

  • We can allow nulls in the foreign key, which is fine for the people ignoring it, but
  • This means the people who require it can end up with tickets that have no priority because it does not prevent a user from leaving it blank.

A simple answer here is to pre-populate your priority lookup table with a value of "Not applicable", perhaps with a hardcoded id of zero. Then we set the default value for the TICKET.priority to zero. This means people can safely ignore it because it will always be valid.

Then, for the customer who paid for it, we just go in after the install and delete the default entry. It's a one-time operation, not even worth writing a script for, and it forces them to create a set of priorities before using the system. Further, by leaving the default of zero in there, it forces valid answers because users will be dinged with an FK violation if they do not provide a real priority.

For this particular example, there is no step 2, because the problem is completely solved at the schema level. To see how to work with step 2, I will make up an example of my own.

Step 2: Unconditional Business Logic

To illustrate step 2, I'm going to make up an example that is not really appropriate to our reader's question, frankly because I cannot think of one for that situation.

Let's say we have an eCommerce system, and one of our sites wants customer-level discounts based on customer groups, while another wants discounts based on volume of order -- the more you buy, the deeper the discount. At this point most programmers start shouting in the meeting, "We'll make them optional!" Big mistake, because it makes for lots of work. Instead we will make them ignorable.

Step 1 is to make ignorable features in the schema. Our common code base contains a table of customer groups with a discount percent, and in the customers table we make a nullable foreign key to the customer groups table. If anybody wants to use it, great, and if they want to ignore it, that's also fine. We do the same thing with a table of discount amounts, we make an empty table that lists threshhold amounts and discount percents. If anybody wants to use it they fill it in, everybody else leaves it blank.

Now for the business logic, the calculations of these two discounts. The crucial idea here is not to make up conditional logic that tries to figure out whether or not to apply the discounts. It is vastly easier to always apply both discounts, with the discounts coming out zero for those users who have ignored the features.

So for the customer discount, if the customer's entry for customer group is null, it will not match to any discount, and you treat this as zero. Same for the sale amount discount, the lookup to see which sale amount they qualify doesn't find anything because the table is empty, so it treats it as zero.

So the real trick at the business logic level is not to figure out which feature to use, which leads to complicatec conditionals that always end up conflicting with each other, but to always use all features and code them so they have no effect when they are being ignored.

Conclusion

Once upon a time almost everybody coding for a living dealt with these situations -- we all wrote code that was going to ship off to live at our customer's site. Nowadays this is less common, but for those of us dealing with it it is a big deal.

The wisdom of the ages is to maintain a common code base. The method suggested here takes that idea to its most complete implementation, a totally common code base in which all features are active all of the time, with no conditionals or optional features (except perhaps in the UI and on printed reports), and with schema and business logic set up so that features that are being ignored simply have no effect on the user.

Categories: Development

Describing Performance Improvements (Beware of Ratios)

Cary Millsap - Fri, 2011-01-21 09:00
Recently, I received into my Spam folder an ad claiming that a product could “...improve performance 1000%.” Claims in that format have bugged me for a long time, at least as far back as the 1990s, when some of the most popular Oracle “tips & techniques” books of the era used that format a lot to state claims.

Beware of claims worded like that.

Whenever I see “...improve performance 1000%,” I have to do extra work to decode what the author has encoded in his tidy numerical package with a percent-sign bow. The two performance improvement formulas that make sense to me are these:
  1. Improvement = (ba)/b, where b is the response time of the task before repair, and a is the response time of the task after repair. This formula expresses the proportion (or percentage, if you multiply by 100%) of the original response time that you have eliminated. It can’t be bigger than 1 (or 100%) without invoking reverse time travel.
  2. Improvement = b/a, where b and a are defined exactly as above. This formula expresses how many times faster the after response time is than the before one.
Since 1000% is bigger than 100%, it can’t have been calculated using formula #1. I assume, then, that when someone says “...improve performance 1000%,” he means that b/a = 10, which, expressed as a percentage, is 1000%. What I really want to know, though, is what were b and a? Were they 1000 and 1? 1 and .001? 6 and .4? (...In which case, I would have to search for a new formula #3.) Why won’t you tell me?

Any time you see a ‘%’ character, beware: you’re looking at a ratio. The principal benefit of ratios is also their biggest flaw. A ratio conceals its denominator. That, of course, is exactly what ratios are meant to do—it’s called normalization—but it’s not always good to normalize. Here’s an example. Imagine two SQL queries A and B that return the exact same result set. What’s better: query A, with a 90% hit ratio on the database buffer cache? or query B, with a 99% hit ratio?

QueryCache hit ratio A90%B99%
As tempting as it might be to choose the query with the higher cache hit ratio, the correct answer is...
There’s not enough information given in the problem to answer. It could be either A or B, depending on information that has not yet been revealed.Here’s why. Consider the two distinct situations listed below. Each situation matches the problem statement. For situation 1, the answer is: query B is better. But for situation 2, the answer is: query A is better, because it does far less overall work. Without knowing more about the situation than just the ratio, you can’t answer the question.

Situation 1QueryCache lookupsCache hitsCache hit ratio A1009090%B1009999%
Situation 2QueryCache lookupsCache hitsCache hit ratio A10990%B1009999%
Because a ratio hides its denominator, it’s insufficient for explaining your performance results to people (unless your aim is intentionally to hide information, which I’ll suggest is not a sustainable success strategy). It is still useful to show a normalized measure of your result, and a ratio is good for that. I didn’t say you shouldn’t use them. I just said they’re insufficient. You need something more.

The best way to think clearly about performance improvements is with the ratio as a parenthetical additional interesting bit of information, as in:
  • I improved response time of T from 10s to .1s (99% reduction).
  • I improved throughput of T from 42t/s to 420t/s (10-fold increase).
There are three critical pieces of information you need to include here: the before measurement (b), the after measurement (a), and the name of the task (here, T) that you made faster. I’ve talked about b and a before, but this I’ve slipped this T thing in on you all of a sudden, haven’t I!

Even authors who give you b and a have a nasty habit of leaving off the T, which is far worse even than leaving off the before and after numbers, because it implies that using their magic has improved the performance of every task on the system by exactly the same proportion (either p% or n-fold), which is almost never true. That is because it’s rare for any two tasks on a given system to have “similar” response time profiles (defining similar in the proportional sense). For example, imagine the following quite dissimilar two profiles:

Task AResponse timeResource100%Total90%CPU10%Disk I/O
Task BResponse timeResource100%Total90%Disk I/O10%CPU
No single component upgrade can have equal performance improvement effects upon both these tasks. Making CPU processing 2× faster will speed up task A by 45% and task B by 5%. Likewise, making Disk I/O processing 10× faster will speed up task A by 9% and task B by 80%.

For a vendor to claim any noticeable, homogeneous improvement across the board on any computer system containing tasks A and B would be an outright lie.

Another DBMS_Scheduler Chain Rule Issue

David Aldridge - Thu, 2011-01-20 05:23
Following on from a recent adventure with a problem validating DBMS_Scheduler chain rules, I hit another issue today. A rule was defined with a step name that does not exist. This happened because there is an odd limit of chain step name lengths (27 bytes I think), and the name of the step in the […]
Categories: BI & Warehousing

And Another Thing …

David Aldridge - Thu, 2011-01-20 04:02
Following on from my recent complaint about an all-time low on the Oracle Forums, does anyone else get the impression that the work there is not just answering questions, but seems increasingly to be correcting all of the incorrect answers? Obviously I have an example in mind. Or has it always been thus?
Categories: BI & Warehousing

XML Schema 1.1 – What you need to know

Ramkumar Menon - Wed, 2011-01-19 11:02

Motivation

XML Schemas, more popularly known as XSDs, provide us a way to describe structure and content of XML Documents. Managed by W3C's XML Schema WG, a part of the XML Activity Group, XML Schemas evolved out of the shortcomings of its simpler and light-weight non-XML predecessor - DTDs, as well as through discussions and conferences of various interest groups across the community. The first W3C Recommendation of the XML Schema specification was released on 2 May, 2001.  The initial edition provided the users a strong type system, enabled users to model rich and complex structural constraints and value-spaces, recognized and allowed expression of namespaces, and also defined the intended behavior of Schema aware processors. This was followed up with a Second Edition in 2004, which wasn't really a newer version, but a minor errata driven release to the First Edition.

While XML Schemas matured, so did other XML based specifications like XSL, XQuery, Web Services, XPath, and several others . The XML Schema WG also ensured that these dependencies feed into the requirements for future versions of the language. The WG also provided an email distribution list that allowed developers and architects alike to exchange ideas, discuss issues and shortcomings, providing an open platform for debating the current and direction of the standard's future.  XML Schema 1.0 provided a platform that allowed architects in W3C and outside to clearly think about what is the next right step towards a "Version 2".

In 2005, W3C conducted a workshop on XML Schema 1.0 user experience. This workshop brought together users, developers and vendors into an open dialogue on potential usability issues, inter-op concerns and set the stage for a future version of the specification that addresses these glitches while adding in "must-have" features that were missed in 1.0. The key takeaways from all the following discussions were features related to Extensibility, Versioning and Validation. Apart from these, there were several very specific schema semantics that were long awaiting a change since 1.0 Ed2.

These led to the birth of a newer 1.1 version of the specification, which will be discussed in greater detail within this article.

Current Status of the Specification

The WG has released two Candidate Recommendation drafts of the following documents

The WG also released a non-normative guide to versioning XML Languages using new features of XML Schema 1.1.

Guide to Versioning XML Languages using new XML Schema 1.1 features

There are few key early implementers of the latest version of the specification namely Apache Xerces and SAXON.

Key Changes since 1.0

The changes since version 1.0 till date can be grouped into the following.

  • Validation
    • Rule based Validation - Love Schematron? 1.1 enables users to express cross-field validations and constraints using XPath 2.0.
  • Extensibility and Versioning
    • Wildcard Enhancements
      • Weak wildcard support - XSD 1.0 uses Unique Particle Attribution rule (UPA) to avoid ambiguity associated primarily with the usage of wildcard content. UPA restricts users from defining certain complex content models. XSD 1.1 attempts to address this using Weak wildcards that disambiguate using precedence rules.
      • Negative Wildcards and Multiple Namespaces
      • Open Content
    • <xsd:all> Model Group Changes  - Finally!
    • Vendor Unique Extensions - Enables vendors to ship their own primitive datatypes and facets
    • Conditional Inclusion - Enable creation of extensible schemas.
  • Miscellaneous Enhancements
    • Conditional Type Assignments
    • Inherited Attributes
    • Default Attribute Group - Enable globally shared set of attribute definitions.
    • Substitution Group Enhancements - Multiple element substitution related changes.
    • ID related changes - Enables, amonst others, mutliple ID attributes for elements.
    • Redefine Replaced by Override - Richer overrides, more interoperability.
    • Target Namespace attribute on local elements and attribute declarations
  • New Datatypes and Facets

One significant aspect of the standard that has been kept unchanged across revisions and editions is the Namespace URI for the schemas. What this means is that the version 1.1 schemas that you create will have the same XSD Namespace URI as a version 1.0 schema.

http://www.w3.org/2001/XMLSchema

In addition to this, almost all of the features in 1.0 have been brought into 1.1 in order to ensure backwards compatibility. What this means is that an XML document defined using a 1.0 schema can be validated using a 1.1 schema processor/validator.  This backward compatibility also ensures that the specification can satisfy dependant requirements from other specifications that rely on syntax and semantics of the 1.0 version of the specification.

1. Validations Rule based Validation

XML Schema 1.1 introduces a new Schema component named <assert> to facilitate rule based validation, along similar lines of Schematron.

User can specify an Boolean XPath expression that will result in the assertions to pass or fail, depending on the evaluation of the expression. Assertion failures are equivalent to a  non-assertion validation failure.

Example 1 <xsd:element name="priceRange">
  <xsd:complexType>
     <xsd:sequence>
         <xsd:element name="minPrice" type="xsd:decimal"/>
         <xsd:element name="maxPrice" type="xsd:decimal"/>
     </xsd:sequence>
    <xsd:assert test="minPrice le maxPrice"/>
</xsd:complexType>
</xsd:element>

In the above example, the assertion checks if the decimal value of minPrice element is less than or equal to the maxPrice element. If an instance document fails this assertion, that document is considered invalid w.r.t the Schema, just like a non-assertion validation failure would cause it to be.

Syntax and Namespace Scope

The asserts are always defined at the end of the type declaration. It can hold a valid XPath 2.0 boolean expression. Being related to XPath 2.0, users can leverage the XPath 2.0 specific functions and operators while building the assertions.

The context node used for the expression evaluation is always the element whose type declaration hosts the mentioned assertion. In the above example, the context node would be the priceRange element. Hence all expressions within the assertions will need to be relative to the priceRange element.

One key restriction that is imposed on the path expressions that can be modeled in an assertion is that one cannot refer to parent or ancestor nodes of the context node. Only context node, or any of its descendants can be referred to within the path expressions. Neither it's siblings nor it's ancestors are permitted.

By this rule, the following assertion is invalid.

<assert test="string-length(ancestor::order/id) > 0"/>

so is

<assert test="string-length(following-sibling::shippingDate)  > 0"/>

and so is

<assert test="doc('pub/docs/customers.xml')/customerInfo[2]/id='12345'"/>

Users can model as many assertions as they want on the type declaration. In that case, the instance document will be considered valid only if none of the assertions for that type declaration have failed.

The namespace scope of the path elements in the expression is determined by the value of the xpathDefaultNamespace attribute on the assert element. If the attribute is absent, its value is assumed to be ##local - which translates into null namespace. This attribute can also be declared to hold any URI, or alternatively configured to use the targetNamespace or the default namespace declared for the XML Schema.

Example 2

<assert test="tns:price > 0" xmlns:tns="www.oracle.com" xpathDefaultNamespace="www.oracle.com"/>

<assert test="price > 0" xpathDefaultNamespace="##targetNamespace"/>

<assert test="price > 0" xpathDefaultNamespace="##defaultNamespace"/>

<assert test="tns:price > 0" xmlns:tns="www.oracle.com" xpathDefaultNamespace="##targetNamespace"/>

<assert test="price > 0" xpathDefaultNamespace="##local"/>

<assert test="ns1:value > ns2:netValue" xmlns:ns1="www.oracle.com" xmlns:ns2="www.abc.com"/>

The last assert is equivalent to not having the xpathDefaultNamespace attribute at all.

Rule based Validation of scalar content

As we described above, <assert>s can be used to define rule-based constraints on complex content. In the event that one wishes to model rules for simple content - for instance, against elements of string or decimal datatype, one can use a new facet available for atomic datatypes - named <assertion>.

Original Declaration:
<element name="evenPriceChangePercent" type="decimal"/>

Declaration with assertion:
<element name="evenPriceChangePercent" type="evenPriceChangePercentType"/>
<simpleType name="priceChangePercentType">
  <restriction base="decimal">
       <assertion test="$value <= 100 and $value >= 0"/>
       <assertion test="$value mod 2 = 0"/>
  </restriction>
</simpleType>

As seen above, this facet provides a default "value" variable that holds the text content of the simple content used for the evaluation. You cannot access any other context nodes within the XPath expression.

2. Extensibility and Versioning Wildcard Related Enhancements Weak Wildcards

Wildcards were introduced into XML Schema to build flexibility into schemas that users build. One could build newer schemas that could validate instances that were defined using an older version of the schema [Backward compatibility], or vice versa [Forward compatibility]. XMLSchema 1.0 provided schema constructs like <any/> and <anyAttribute/> for this purpose. These constructs enable elements and attributes that aren't explicitly defined in the schema, to occur in a valid XML instance document, providing way for extensible content models.

For instance,

Example 3 <element name="Address">
  <complexType>
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string"/>
          <!--allow any element from any namespace to occur -->
         <any namespace="##any" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

1.0 allowed for adding these wildcards at any position within your type declaration,as long as there isn't an ambiguity with explicitly declared elements.

Look at the example below.

Example 4 <element name="Address">
  <complexType>
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
          <!--allow any element from any namespace to occur -->
         <any namespace="##any" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

With the above schema in mind, consider the following XML document.

Example 5 <Address>
   <street>1, Courthouse Square</street1>
  <city>Hill Valley</city>
  <state>CA</state>
  <zip>91919</zip>
</Address>

With this document, it is impossible to state if zip element should be associated with the named element zip, or the wildcard any element. This schema is thus prohibited in XML Schema 1.0. The rule that prohibits this is termed as Unique Particle Attribution (UPA) Rule.

With 1.1, the UPA restriction is relaxed - it is no longer forbidden to have the kind of XML Schema mentioned in Example 4. [competition between element and wildcard]. When there is such an ambiguity, the named element definition takes precedence. In this case, since there is an element named "zip" that can resolve the ambiguiity, that one is chosen over the wildcard during resolution.

Also considered legal is a competition between two wildcards. However, competition between two elements is still considered a violation of the rule.

For example, the following XML schema is still invalid since the processing application will not be able to disambiguate the <direction> element in the XML Instance if their respective siblings were absent.

Example 6 <element name="TimeTravel">
   <complexType>
      <choice>
      <sequence>
          <element name="direction" type="string"/>
           <element name="year" type="integer" minOccurs="0"/> 
      </sequence>
      <sequence>
          <element name="direction" type="string"/>
           <element name="universeName" type="string" minOccurs="0"/> 
      </sequence>
     </choice>
  </complexType>
</element>

Multiple Namespaces and Negative Wildcards

In XML Schema 1.0, you had the capability to specify the namespace URI for a wildcard element. You could either specify

  • A list of one or more specific URIs
  • ##other - which means any URI other than the targetNamespace
  • ##targetNamespace - which is self explanatory
  • ##any - which means any URI
  • ##local - which indicates null namespace.
Example 7 <any namespace="##other"/>
<any namespace="http://www.delorean.com http://www.fluxcapacitor.com"/>
<any namespace="##targetNamespace"/>
<anyAttribute namespace="##local"/.>

In XML Schema 1.1, you have more ways to control your wildcards. You could in fact state that your wildcards NOT come from a namespace UR or multiple Namespace URIs.

In addition to this, you can also constrain the potential qualified name of the wildcard through the new schema constructs.

Example 8 <any notQName="tns:Almanac tns:IceHockey"/>
<anyAttribute notNamespace="##targetNamespace"/>
<any notNamespace="##defaultNamespace"/>
<any notNamespace="http://www.fluxcapacitor.org"/>

Other constraints you can impose are:

  • Ensure your wildcards do not have the same name as any of it's siblings.
  • Ensure your wildcards do not have the same name as any of the existing global declarations in the schema.
Example 9 <any notQName="##definedSibling"/>
<any notQName="##defined"/>

Take a look at the schema below.

Example 10 <element name="Address">
   <complexType>
      <sequence>
           <element name="street" type="string"/>
           <element name="city" type="string"/>
           <element name="state" type="string"/>
           <element name="zip" type="string"/>
            <any notQName="##definedSibling" namespace="##local"/>
      </sequence>
  </complexType>
</element>

This will fail validation for the following XML instance.
<Address>
   <street>1, Courthouse Square</street1>
  <city>Hill Valley</city>
  <state>CA</state>
  <zip>91919</zip>
  <zip>94321</zip>
</Address>

Open Content

Open Content allows for defining elements to possess child element or attribute content other than the ones explicitly defined in it's content model, and allow them to be available at any position within its content.

In 1.0, you needed to explicitly position your <xsd:any/> declarations within your choice or sequence content models. In 1.1, you can declare open content for your elements at one place - within the complexType definition, or at the schema level. On top of this, you can choose to distribute your open content interleaved between your named child elements [interleaved], choose to have them after all of the child elements. [suffixed], or disable inherited openContent behavior.

Example 11 - Interleaved Open Content <element name="Address">
  <complexType>
    <openContent mode="interleave">
         <any/>
    </openContent>

     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

Valid Instances for the Schema

Example 1:

<Address>
   <street>1, Courthouse Square</street1>
   <boo/>
  <city>Hill Valley</city>
   <foo/>
   <bar/>

  <state>CA</state> 
  <zip>91919</zip>
   <boo2/>
</Address>

Example 2:

<Address>
   <street>1, Courthouse Square</street1>
   <boo/>
   <foo/>
   <bar/>
  <city>Hill Valley</city> 
  <state>CA</state> 
   <boo2/>
  <zip>91919</zip>
</Address>

Note that the maxOccurs="unbounded" and minOccurs="0" attributes on the <any/> is implicit - which explains how one is able to have multiple wildcard elements in your XML instance document.

Example 12: Suffixed Open Content
<element name="Address">
  <complexType>
    <openContent mode="suffix">
       <any/>
    </openContent>

     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>
</element>

Valid Instance for the Schema

<Address>
   <street>1, Courthouse Square</street1> 
  <city>Hill Valley</city> 
  <state>CA</state> 
  <zip>91919</zip>
   <boo/>
   <foo/>
   <bar/>
   <boo2/>

</Address>

The third use-case - mode="none" is typically used when you are importing and extending a complexType from a foreign schema, but do not wish to inherit the openness of the inherited type definition.

The wildcard <any/> within the <openContent> section can be combined with the wildcard constraints discussed in the earlier section as well. [e.g. <any notQName="fc:doc"/>]

Another variant of of the openContent use-case is the one where user wishes to model adding wildcards within any element content defined in the schema - i.e. a schema-wide openContent.

This is supported through a schema construct <defaultOpenContent> declared as a direct child of the <schema> element. See example below.

Example 14 (I skipped "13") <schema targetNamespace="..." xmlns="....">
<defaultOpenContent mode="interleave" appliesToEmpty="true">
   <any/>
</defaultOpenContent>

<element name="Order">
  ....
</element>

<element name="Info">
   <complexType/>
   <attribute name="id" type="string"/>
</element>

<element name="BillingAddress" type="tns:BillingAddressType"/>

<element name="ShippingAddress" type="tns:ShippingAddressType"/>

  <complexType name="BillingAddressType"> 
     <sequence>
          <element name="street1" type="string"/>
          <element name="street2" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>

  <complexType name="ShippingAddressType"> 
     <sequence>
          <element name="street" type="string"/>
          <element name="city" type="string"/>
          <element name="state" type="string"/>
          <element name="zip" type="string" minOccurs="0"/>
     </sequence>
  </complexType>


</schema>

This schema can be used to generate XML documents where arbitrary elements can occur between the contents of ShippingAddress and BillingAddress. Even the empty element Info can have open content within it attributed to the appliesToEmpty attribute on the <defaultOpenContent> declaration.

Valid Instance for the above XSD:

<Order>
   <Info id="123">
        <HelloWorld/>
   </Info>
  <BillingAddress>
      <Welcome6>123</Welcome6>
      <street1>1, Courthouse Square</street1> 
      <street2>Apt 007</street2> 
      <boo2/> 
      <city>Hill Valley</city> 
      <state>CA</state> 
      <zip>91919</zip> 
      <foo3/> 
</BillingAddress>
  <ShippingAddress>
      <Welcome>123</Welcome>
      <street>1, Courthouse Square</street>  
      <boo/> 
      <city>Hill Valley</city> 
      <state>CA</state> 
      <zip>91919</zip> 
      <foo/> 
</ShippingAddress>
</Order>

<xsd:all> Group Changes

The "All" Model group was bundled with several restrictions when it was introduced in XML Schema 1.0.

1. The group disallowed multiple occurence elements to be a part of the content model.   The following is illegal in XML Schema 1.0

Example 15 <complexType name="FluxCapacitorType">
   <all>
       <element name="timeCalibrator" type="string" maxOccurs="unbounded"/>
       <element name="needsRecharge" type="boolean" minOccurs="3" maxOccurs="unbounded"/>
  </all>
</complexType>

Elements within <all> groups were supposed to have maxOccurs=1 and a minOccurs of 0 or 1.

i.e. elements occur in any order, but each element occurs exactly once, if present.

2. <all> group cannot be nested within another model group. What this means is that you cannot have an <all> nested within a <sequence> or a <choice> model group. Thus the following is illegal in 1.0.

Example 16 <complexType name="FluxCapacitorType">
  <choice>
       <element name="autoFunction" type="AutoFunctionType"/>
       <all>
            <element name="timeCalibrator" type="string" maxOccurs="unbounded"/>
            <element name="needsRecharge" type="boolean" minOccurs="3" maxOccurs="unbounded"/>
      </all>
   </choice>
</complexType>

3. You cannot extend a non-empty BaseType with an <all> content model. The following is illegal in 1.0

Example 17 <complexType name="BaseTimeTravelMachineType">
  <all>
        <element name="timeComputer" type="string"/>
        <element name="carrier" type="CarrierType"/>
  </all>
</complexType>

<complexType name="HighSpeedTimeTravelMachineType">
  <complexContent>
       <extension base="BaseTimeTravelMachineType">
            <all>
                   <element name="TravelerProfileReader" type="ProfileReaderType"/>
          </all>
       </extension>
   </complexContent>
</complexType>

4. You cannot have wildcards within <all> groups.  The following is illegal in 1.0.

Example 18 <complexType name="BaseTimeTravelMachineType">
  <all>
       <any/>
        <element name="timeComputer" type="string"/>
        <element name="carrier" type="CarrierType"/>
  </all>
</complexType>

XML Schema 1.1 has legalized all the above models.

Vendor Unique Extensions

Vendors can now define their own primitive datatypes and facets. For instance, it may provide support for a new primitive datatype called string, with it's own implementation defined facets. These datatypes will be in a vendor defined namespace in order to distinguish them from XSD's predefined datatypes. The treatment of  the vendor defined datatype depends on each vendor - and evidently, it may not be supported by a processor implemented by another vendor.

Example 19 <!--new custom integer datatype -->
<element name="age" type="xdk:integer"/>
<!--new custom 'era' facet -->
<simpleType name="TimeType">
     <extension base="xdk:oracleDateTime">
            <xdk:era="Andromedan"/>
      </extension>
</simpleType> Conditional Inclusion

This feature is primarily used to ensure that XML documents that may be defined down the future using a later version of XML Schema language [say 5.5] can be processed in compatibility mode by a XML Processor that supports a prior version of  XML Schema [starting from 1.1].  For instance, one of the element declarations in a user defined XML Schema may use a new construct that was introduced in XML Schema 5.5. If you need to process this XML Schema using an XML Schema 1.1 compliant processor, you have to have a feature that allows you to pre-process and selectively interpret the constructs that the 1.1 version processor understands.

For this purpose, XML Schema 1.1 introduces a new set of attributes in the Schema Versioning Namespace, as listed below.

The Schema Versioning Namespace has a URI - http://www.w3.org/2007/XMLSchema-versioning. Within this namespace URI are four attributes.

  1. vc:typeAvailable
  2. vc:typeUnavailable
  3. vc:facetAvailable
  4. vc:facetUnavailable
  5. vc:minVersion
  6. vc:maxVersion

Look at the 2 examples below. In the first example, the user intends to define an element named TimeMachine that can be interpreted by an XML Schema Processor that complies with version 1.6, as well as one that supports version 1.1.

Example 20 <!--The below declaration is accepted for pre-processing for XML Schema versions 1.1 [inclusive], but less than 1.6. [exclusive] -->
<element name="TimeMachine" vc:minVersion="1.1" vc:maxVersion="1.6">
   <complexType>
         <sequence>
           .....
</element>
<!--The below declaration is accepted for pre-processing for XML Schema versions 1.6 or later. It may have constructs that are not understood by 1.1 processors.
-->

<element name="TimeMachine" vc:minVersion="1.6">
      <complexPhasedDatatype>
          <prioritizedSequence>
                ...
</element>

In the second example, listed below, the user intends to signal the usage of a vendor defined datatype or facet through the first 4 schema versioning attributes listed above.

Example 21 <!--line 1 is for processors that implement the custom datatype, whereas line 2 is used by other processor implementations -->
<element name="EmmetBrownsLabHeight" vc:typeAvailable="xdk:feet" type="xdk:feet"/>
<element name="EmmetBrownsLabHeight" vc:typeUnavailable="xdk:feet" type="xsd:integer"/>

<!--declaration 1 is used by processor that implements the custom minLength facet. The latter declaration is the fallback used by other processors ->
<element name="ItemCode" vc:facetAvailable="xdk:minLength">
    <simpleType>
       <restriction base="string">
              <xdk:minLength value="1,2"/>
       </restriction>
    </simpleType>
</element>
<element name="ItemCode" vc:facetUnavailable="xdk:minLength" type="string"/>

3. Miscellaneous Enhancements Conditional Type Assignments

XML Schema 1.1 allows for dynamic type assignment based on XPath 2.0 boolean condition expressions.

See example below.

Example 22 <!--inline alternative type definitions -->
<element name="TimeTravel" type="TravelType">
      <alternative test="@direction='Future'">
          <complexType>
              <complexContent>
              <restriction base="TravelType"
                         ....
<!--        some past travel related elements go here -->
            </complexType>
       </alternative>
      <alternative test="@direction='Past'">
          <complexType>
              <complexContent>
              <restriction base="TravelType"
                         ....
   <!--        some future travel related elements go here -->
            </complexType>
       </alternative>
  </element>
                          OR
<!--Named alternative type definitions -->
<element name="TimeTravel" type="TravelType">
   <alternative test="@direction='Future' type="FutureTravelType"/>
   <alternative test="@direction='Past' type="PastTravelType"/>
</element>

Few points to note here.

  • You can only access attributes of the context node within the xpath expression. You cannot use child/descendant elements in the expression as you would have seen in the assert statements earlier in the article, nor anything on the ancestor axis. In the above example, direction is an attribute defined within  the complexType TravelType that is used to define the TimeTravel element.
  • The alternative types should be datatypes that are derived from the actual type defined on the element. In the above example, FutureTravelType and PastTravelType are derived from TravelType.
  • Just as you would model the namespaces in asserts, you could use the xpathDefaultNamespace attribute to qualify the xpath expression on the alternatives.

Inherited Attributes

Inheriting attributes allows access to attributes of ancestor elements within descendant elements. Though inheriting does not allow the attributes to actually appear on the descendant element in the XML instance, they can be effectively used within asserts and type alternatives for the descendant element. An attribute can be declared as inheritable by defining inheritable="true" on the attribute declaration, as illustrated below.

Example 23 <element name="TimeTravelType">
    <complexType>
         <sequence>
               <element name="GadgetType">
                    <alternative test="@mode='Past' type="PastGadgetType"/>
                    <alternative test="@mode='Future' type="FutureGadgetType"/>
              </element>
             <element name="dimension">
                 ....
                <assert test="@length > 200 and @mode='Past'"/>
                <assert test="@length <= 200 and @mode='Future'"/>
        </sequence>
        <attribute name="mode" inheritable="true"/>
    </complexType>
</element>

Note that defining an inheritable attribute does not prevent schema designer to define attributes with the same name on the descendant element datatypes. In that case, the local declaration prevails.

Default Attribute Group

Default attribute group defines a set of global attributes that can be accepted by all complexType definitions directly defined in the schema file. [not applicable to imported/included components]

Example 24 <schema targetNamespace="...."
                   defaultAttributes="myLocalAttrs"
                   ....>
     <element name="AllTimePieces">
               ...
     <element>
     <element name="MyTimePiece">
                   ...
      <element>
      <element name="HisMuchBetterTimePiece">
                ....
         </element>

        <attributeGroup name="myLocalAttrs">
             <attribute name="tpId" type="ID"/>
         </attributeGroup>
</schema>

<AllTimePieces tpId="NONE">
         <MyTimePiece tpId="0">
                        ....
          </MyTimePiece>
          <HisMuchBetterTimePiece tpId="1">
                        ...
           </HisMuchBetterTimePiece>
   </AllTimePieces> 

This eliminates the need for redundant reference to the attribute group within all complexType definitions that needed to share the same set of attributes.

Substitution Group Enhancements

SubstitutionGroups in XML Schema 1.0 allows elements to be substitutable for other elements. To be precise, it allows for replacing an element with another. XML Schema 1.1 enhances this functionality by allowing an element to be substitutable for one or more elements

Example 25 <!--SubstitutionGroups in XML Schema 1.0 -->
<element name="shipComment" substitutionGroup="po:Comment" type="ShipCommentType"/>
<element name="billComment" substitutionGroup="po:Comment" type="BillComentType"/>

<!--SubstitutionGroups in XML Schema 1.1 ->
<element name="Flute" substitutionGroup="po:MusicalInstrument po:WindInstrument" type="FluteType"/>
<element name="MusicalInstrument" type="po:MusicalInstrumentType"/>
<element name="WindInstrument" type="po:WindInstrumentType"/>

As seen in Example 25, the element Flute can be substituted for either the MusicalInstrument element, or the WindInstrument element, provided FluteType datatype is derived from MusicalInstrumentType and WindInstrumentType.

ID related changes

XML Schema 1.1 has revised ID semantics to allow elements to possess more than one xsd:ID attribute. XSD 1.0 had forbidden this usage for ensuring compatibility with DTDs. Schemas that intend to be compatible can choose to not use this feature.  It also allows ID attributes to have default and fixed values - again something that was forbidden in 1.0.

Example 26
<element name="Fruit">
   <complexType>
     <sequence>
          <element name="taste" type="f:TasteType"/>
           ...
      </sequence>
     <!--Illustrating more than one ID on an element -->
     <attribute name="fruitUID" type="ID"/>
     <attribute name="flavourUID" type="ID"/>
   <!--illustrating default value on an ID type attribute -->
    <attribute name="locationCode" type="ID" default="US-CA"/>
</element>

Redefine Replaced by Override

<redefine> construct in XML Schema 1.0 enabled users to extend or restrict element type declarations. What it did not allow was to create a new definition for the same element when redefining it.

Example 27 <!--Legal redefine in XML Schema 1.0 -->
<schema .....>
   <redefine schemaLocation="http://www.greatschemas.org/invoice.xsd">

    <complexType name="BillingAddressType">
<!--BillingAddressType is defined in the included schema above, and is being redefined -->
            <extension base="gsc:BillingAddressType">
                  <sequence>
                        <element name="BillingCode" type="string"/>
                  </sequence>
            </extension>
    </complexType>

    <!--
        Illegal redefine in XML Schema 1.0  where BillingAddressType has been defined in the included schema  above
       -->

      <complexType name="BillingAddressType">
                  <sequence>
                        <element name="TotallyDifferentBillingStuff" type="string"/>
                  </sequence>
            </extension>
    </complexType>
</redefine>

Moreover, XML Schema 1.0 had many conflicting and non-interoperable implementations for <redefine> that 1.1 decided to deprecate the <redefine> functionality and replace it with a richer <override> construct instead.

Example 28 <!--Legal override in XML Schema 1.1 showing extension of types-->
<schema .....>
   <override schemaLocation="http://www.greatschemas.org/invoice.xsd">

    <complexType name="BillingAddressType">
<!--BillingAddressType is defined in the included schema above, and is being redefined -->
            <extension base="gsc:BillingAddressType">
                  <sequence>
                        <element name="BillingCode" type="string"/>
                  </sequence>
            </extension>
    </complexType>

    <!--
        Legal override in XML Schema 1.0  where BillingAddressType has been defined in the included schema  above
       -->

      <complexType name="BillingAddressType">
                  <sequence>
                        <element name="TotallyDifferentBillingStuff" type="string"/>
                  </sequence>
            </extension>
    </complexType>
</override>

Note that <redefine>  has been deprecated, but not removed yet. The WG is still looking for feedback from users on this construct.  It MAY be removed from future versions of the specification.

Target Namespace attribute on local elements and attribute declarations

XML Schema 1.1 allows users to define targetNamespace on local element and attribute declarations. The namespace URI may be different from the targetNamespace defined on its ancestors or the schema element.

Example 29 <schema targetNamespace="http://xmlns.oracle.com/definitions" ..... elementFormDefault="qualifiied">
    <element name="Address">
           <complexType>
               <sequence>
                     <element name="street1" targetNamespace="www.alternatens.com/defns"/>
                       ....
               </sequence>
                <attribute name="id" targetNamespace="http://xmlns.groceries.com/defns"/>
             </complexType>
         </element>
</schema>

<schema targetNamespace="http://xmlns.oracle.com/definitions" ..... elementFormDefault="qualifiied">
    <import namespace="www.foreign.com/defns" schemaLocation="Alt_Objects.xsd"/>
    <element name="Address">
           <complexType>
            <complexContent>
              <extension base="ForeignAddressType">
               <sequence>
                     <element name="street1" targetNamespace="www.foreign.com/defns"/>
                       ....
               </sequence>
                <attribute name="id" targetNamespace="www.foreign.com/defns"/>
             </complexType>
         </element>
</schema>

4. New Datatypes and Facets

XML Schema 1.1 added several new core datatypes into its existing library.

xsd11_datatypes

1. The anyAtomicType datatype

This datatype has been newly introduced as the base type for all atomic datatypes in the Schema's datatype library. [i.e. string, float,boolean etc]. It extends from anySimpleType.

"In XML Schema, a simple type is either a list type, a union type, or an atomic type; however, these three kinds of simple type are not recognized explicitly in the type hierarchy. For XPath, it was necessary to distinguish atomic types from the other kinds of simple type, so xdt:anyAtomicType was invented to achieve this."

                - Michael Kay, SAXONICA

2. New Numeric Datatypes

A new datatype named precisionDecimal has been added to support IEEE-754 floating-point decimal datatypes. precisionDecimals carry a numeric value, an arithmetic precision and a sign. Apart from distinguishing between positive and negative zero, this datatype also holds NaN and positive/negative infinity in it's value space.

Example 30 <price>1200.04</price>
<price>INF</price>
<price>-INF</price>
<price>NaN</price>

3. Date/time Datatypes

The following new datatypes - dateTimestamp, dayTimeDuration and yearMonthDuration have been added to the library. dateTimestamp extends the existing dateTime datatype with a mandatory explicitTimezone facet. [the timezone portion was optional in the dateTime datatype.]

<element name="shipDate" type="dateTimeStamp"/>

<shipDate>2010-02-01T12:03:00-08:00</shipDate>
<shipDate>2010-02-01T12:03:00Z</shipDate>

Both new duration related datatypes extend from the existing duration datatype and does a simple restriction on its lexical space.

<!--2 years and 3 months yearMonthDuration -->
<sampleYearMonthDuration>P2Y3M</sampleYearMonthDuration>
<!--1 day and 6 hours dayTimeDuration-->
<sampleDayTimeDuration>P1D6H</sampleDayTimeDuration>

5. Next Steps

Several implementations are under development. This includes the upcoming versions of Xerces, and the SAXON processor. 

You can contribute to the specification by submitting your comments to the public comments mailing list for the standard - www-xml-schema-comments@w3.org. Here is the archive.

6. Credits

Roger Costello's Tutorial is one of the best you can grab to get to the next level of details on the specification. He has done a fabulous job in documenting all major features to fine levels of detail. You can find a link to his tutorial in the next section.

6. References

1. XML Schema 1.1 Part 1: Structures

2. XML Schema 1.1 Part 2: Datatypes

3. Roger Costello's XML Schema Tutorial

4. XML Schema 1.1, Part 1: An introduction to XML Schema 1.1 - IBM

5. XML Schema 1.1, Part 2: An introduction to XML Schema 1.1 - IBM

6. XML Schema 1.1, Part 3: An introduction to XML Schema 1.1 - IBM

Oooohhh... shiny!

alt.oracle - Tue, 2011-01-18 22:52
I went to last year's Oracle Open World. I'd always wanted to go, but having been a consultant for so many years, those opportunities don't always come your way. In my experience, companies will spring for their own employees to go to Open World, but "no way" to that lousy, overpaid consultant who probably won't even be here next week. That leaves it up to the consulting company, whose take on things is usually, "If you don't already know everything they're talking about at Open World, then why did we hire you? Get back to work!" But since I work for a good consulting company, they offered me the chance to go.

Open World is a blast. If you're a geeky Oracle person like me, it's a complete nerd-o-gasm. First of all, Oracle's always announcing the "next big thing" – this year, it was the Oracle Linux kernel (perhaps the subject of a future post) and the latest in Exadata. Then you have your session speakers, most of which are pretty good. The technology booths full of people trying to sell you stuff are always cool. Of course, best of all is all the free swag you get. I came home with more techie junk than you can shake a datafile at. Let me tell you, it takes some mad ninja skilz to nab 11 t-shirts from Open World and get them home. I had to throw away all my underwear just to get them to fit in my luggage (don't ask me how the flight home was...).

Of course, the real focus of any Open World is same as that of a lot of the software industry – better, faster, stronger, more. Newer and shinier. What you have isn't what you need. I can't fault them for this – they need to keep selling stuff to compete and to stay in business, and innovation is a huge part of what we do. Progress is good. But sometimes a DBA needs to distinguish between something that represents progress and something that represents a big ol' pile of shiny.

I talked last time about how being a good DBA means having a healthy dose of skepticism. That has to apply to "new feature-itis" too. Part of what I do involves evaluating new technologies. Not only do I have to evaluate the tech to verify that it does what it says it does, I need to assess that its benefits are worth the time, risks and cost of adopting it. As an evaluator, there's an implied trust with my employers that if I recommend a shiny, new feature, it's because it will benefit their interests – not necessarily mine. I haven't seen it often, but I can remember working with more than one DBA who didn't share my take on this. I've come to expect non-technical people to fall into the whole "Look! Shiny!" thing when it comes to new tech. But some technical folks in positions of authority see new tech as way to 1) pad their resume ("why yes I've worked with feature X, I helped bring it into my last company"), or 2) make them indispensable, since they adopted it and are the only ones who understand it. When I was a newbie DBA, I knew a senior DBA who did just that - repeatedly. Everybody could see it, but nobody was in a position to do anything about it. Then, he left and the rest of us were put in the position of having to support this big, expensive, shiny nightmare.

Flying along the bleeding edge can be a bumpy ride. Resist the urge to pad your resume at the expense of your employer. Otherwise, your big ol' pile of shiny might become a big ol' pile of something else.
Categories: DBA Blogs

Solving ORA-24172: rule set %s.%s has errors

David Aldridge - Tue, 2011-01-18 09:01
DBMS_Scheduler chains are a joy to use, until they stop being a joy and start being a real pain. I modified the logic of a process, dropping one stored procedure and replacing it with another (instead of writing out a list of files to a control file so that a cron job can scp them […]
Categories: BI & Warehousing

Script for Time Dimension Table

Keith Laker - Mon, 2011-01-17 09:06
Note - This blog post was updated on Nov. 14, 2012 with a new script.  This as been simplified a bit and includes half year.

One of the more common requests I get is a script for creating time dimension tables for Oracle OLAP. The following script will create a time dimension table for a standard calendar. It starts by creating a table with dimension members and labels. The second part of the script fills in end date and time span attributes. The section that creates end date and time span can be easily adapted for completing other calendars (e.g., fiscal) where the members have already been filled in.


--
-- Create time dimension table for a standard calendar year (day, month,
-- quarter, half year and year).
--
-- Drop table.
--
--DROP TABLE time_calendar_dim;
--
-- Create time dimension table for calendar year.
--
-- First day if the next day after TO_DATE('31/12/2010','DD/MM/YYYY').
-- Number of days is set in CONNECT BY level <= 365.
--
-- Values for end date and time span attributes are place holders. They need
-- to be filled in correctly later in this script.
--
CREATE TABLE time_calendar_dim AS
WITH base_calendar AS
  (SELECT CurrDate          AS Day_ID,
    1                       AS Day_Time_Span,
    CurrDate                AS Day_End_Date,
    TO_CHAR(CurrDate,'Day') AS Week_Day_Full,
    TO_CHAR(CurrDate,'DY')  AS Week_Day_Short,
    TO_NUMBER(TRIM(leading '0'
  FROM TO_CHAR(CurrDate,'D'))) AS Day_Num_of_Week,
    TO_NUMBER(TRIM(leading '0'
  FROM TO_CHAR(CurrDate,'DD'))) AS Day_Num_of_Month,
    TO_NUMBER(TRIM(leading '0'
  FROM TO_CHAR(CurrDate,'DDD'))) AS Day_Num_of_Year,
    UPPER(TO_CHAR(CurrDate,'Mon')
    || '-'
    || TO_CHAR(CurrDate,'YYYY')) AS Month_ID,
    TO_CHAR(CurrDate,'Mon')
    || ' '
    || TO_CHAR(CurrDate,'YYYY') AS Month_Short_Desc,
    RTRIM(TO_CHAR(CurrDate,'Month'))
    || ' '
    || TO_CHAR(CurrDate,'YYYY') AS Month_Long_Desc,
    TO_CHAR(CurrDate,'Mon')     AS Month_Short,
    TO_CHAR(CurrDate,'Month')   AS Month_Long,
    TO_NUMBER(TRIM(leading '0'
  FROM TO_CHAR(CurrDate,'MM'))) AS Month_Num_of_Year,
    'Q'
    || UPPER(TO_CHAR(CurrDate,'Q')
    || '-'
    || TO_CHAR(CurrDate,'YYYY'))     AS Quarter_ID,
    TO_NUMBER(TO_CHAR(CurrDate,'Q')) AS Quarter_Num_of_Year,
    CASE
      WHEN TO_NUMBER(TO_CHAR(CurrDate,'Q')) <= 2
      THEN 1
      ELSE 2
    END AS half_num_of_year,
    CASE
      WHEN TO_NUMBER(TO_CHAR(CurrDate,'Q')) <= 2
      THEN 'H'
        || 1
        || '-'
        || TO_CHAR(CurrDate,'YYYY')
      ELSE 'H'
        || 2
        || '-'
        || TO_CHAR(CurrDate,'YYYY')
    END                      AS half_of_year_id,
    TO_CHAR(CurrDate,'YYYY') AS Year_ID
  FROM
    (SELECT level n,
      -- Calendar starts at the day after this date.
      TO_DATE('31/12/2010','DD/MM/YYYY') + NUMTODSINTERVAL(level,'DAY') CurrDate
    FROM dual
      -- Change for the number of days to be added to the table.
      CONNECT BY level <= 365
    )
  )
SELECT day_id,
  day_time_span,
  day_end_date,
  week_day_full,
  week_day_short,
  day_num_of_week,
  day_num_of_month,
  day_num_of_year,
  month_id,
  COUNT(*) OVER (PARTITION BY month_id)    AS Month_Time_Span,
  MAX(day_id) OVER (PARTITION BY month_id) AS Month_End_Date,
  month_short_desc,
  month_long_desc,
  month_short,
  month_long,
  month_num_of_year,
  quarter_id,
  COUNT(*) OVER (PARTITION BY quarter_id)    AS Quarter_Time_Span,
  MAX(day_id) OVER (PARTITION BY quarter_id) AS Quarter_End_Date,
  quarter_num_of_year,
  half_num_of_year,
  half_of_year_id,
  COUNT(*) OVER (PARTITION BY half_of_year_id)    AS Half_Year_Time_Span,
  MAX(day_id) OVER (PARTITION BY half_of_year_id) AS Half_Year_End_Date,
  year_id,
  COUNT(*) OVER (PARTITION BY year_id)    AS Year_Time_Span,
  MAX(day_id) OVER (PARTITION BY year_id) AS Year_End_Date
FROM base_calendar
ORDER BY day_id;
);
--
COMMIT;
Categories: BI & Warehousing

Pages

Subscribe to Oracle FAQ aggregator