File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes XML and Related Technologies and the fly likes XSD date format is required Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » XML and Related Technologies
Bookmark "XSD date format is required" Watch "XSD date format is required" New topic

XSD date format is required

samir vasani
Ranch Hand

Joined: Nov 24, 2010
Posts: 64

Currently i am using following syntax which give me output in YYYY-DD-MM.

I need output in MM/DD/YYYY.
Please help me out to solve this.
g tsuji
Ranch Hand

Joined: Jan 18, 2011
Posts: 633
Currently i am using following syntax which give me output in YYYY-DD-MM.

A casual look of the pattern would rather show an attempt, pertinent or not, to give you output in YYYY-MM-DD with the restriction to centuries 19xx and 20xx only. (I can suppose it is a typo.)

But as far as the final goal is concern, it is somewhat a misleading pattern. The pattern seems to suggest you would accept 19xx-1-1, say, for Jan 1, 19xx. But this is absolutely not allowed. As it would already invalidated by the base type xs:date.

Another thing to point out is that the pattern elaborate quite a bit on specifying 30d-month/31d-month as well as 28/29 Feb. In a standalone regex view, it does probably a very good job. But, if you want to use it in xsd with the base type xs:date, it is very much unnecessary as the validating engine for the xs:date type would already do that checking for you. It is, hence, much unnecessary and blurring the issue.

To conclude, the restriction of xs:date is simply doing two things: [1] accepting only centuries 19xx and 20xx, [2] forbidding local time zone to slip into the data. For these two purposes, you can do it very simply by taking a pattern value like this.

That is at least my quick analysis of it. It seems very liberal pattern, but in fact, the xs:date would take care of the rest.

As to the wish to get an output or input of form MM/DD/YYYY, it is a twist very much in contradition with the intent of xs:date to being as much less dependent on the local or country's usage as possible as xml and xsd to that effect as well take i18n very much in mind from within and from the start. I dare say there is no way of doing a xs:restriction based on xs:date. The only way out is that you accept xs:string as the base type and make the pattern very much like what you are using or what you are borrowing from the regex pure rendering of the format. In that case, all the elaboration of long/short month etc is needed. A transcription of the shown pattern can certainly have it rewritten to the equivalent form for MM/DD/YYYY. If you find it too difficult to do that, you can attempt to locate a regex library kind of page to borrow a pattern to that effect. But, a base type of xs:string for the purpose of emulating xs:date is very much counter-productive. If you insist having that, it is better to leave that specific validating to the application code itself where more apt methods would then be available to you. That is only my opinion... you can sure make your own judgement and decision.
I agree. Here's the link:
subject: XSD date format is required
It's not a secret anymore!