Alan
>
> In the Open Travel Alliance (www.opentravel.org) version 1 specification we
> ran into the time zone issue, where UTC notation does not appear to solve
> the problem of daylight savings times or those localities that do not
> follow daylight savings time.
I thought the correct ISO 8601 procedure for this was to adjust the time zone
information to reflect the current noon time. So, for example, the time zone at
Greenwich is currently 0100 as the UK is on British Summer Time, even though Greenwich
defines the meridian. If this is not the case then we should try to change ISO 8601
before we try to correct the XML Schema definitions based on them.
Incidentally, we could also add a "time saving adjustment" attribute to dates to
record the adjustment currently in force.
>We covered the issue by putting in longitude and
> latitude -- what we called GeoCodes -- using ISO 6709 notation to indicate
> precise locations. With GeoCodes, trading partners need to translate
> locations into time policies of those locations. With a growing number of
> business applications based on precise geographic locations (not just for
> time zones) you may want to consider adding geographic notation as a datatype.
>
> See http://www.ftp.uni-erlangen.de/pub/doc/ISO/english/ISO-6709-summary for
> a summary of ISO 6709 notation. Best regards.
This looks like a good candidate for using patterns, though there is an interesting
problem relating to the Degrees & Decimals variant, which could be more safely handled
using the basic decimal datatype. How does the following grab you:
<xsd:simpleType name="ISO6709position" base="xsd:string">
<xsd:pattern value="([+-][0-9]{1,3}[.][0-9]{1,2} |
[+-][0-9]{1,3}[0-5][0-9][.]0-9]{1-3} |
[+-}[0-9]{1,3}[0-5][0-9][0-5][0-9][.][0-9]{1-2})
([+-][0-9]{1,3}[.][0-9]{1,2} |
[+-][0-9]{1,3}[0-5][0-9][.]0-9]{1-3} |
[+-}[0-9]{1,3}[0-5][0-9][0-5][0-9][.][0-9]{1-2})"/>
<xsd:minInclusive value="-0"/>
<xsd:maxInclusive value="+1795959.99"/>
</xsd:simpleType>
This would not allow the truncated forms, but would it not be a good idea to drop
these in any case for travel based applications? (Any volunteers to work out all the
combinations of how you could do this?)
Note that there is a problem with the minInclusive and maxInclusive values if you are
using strings as your basic datatype rather than decimals as you have to work on the
character position of the string rather than the decimal value, so -0 is the lowest
pairing of character positions and +179 degrees, 59 minutes and 59.99 seconds is the
longest permitted string.
If you stayed with the decimal degrees variant only this could be simplified to
<xsd:simpleType name="decimalISO6709position" base="xsd:decimal">
<xsd:minInclusive value="-180"/>
<xsd:maxInclusive value="180"/>
</xsd:simpleType>
Martin Bryan
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.org
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
