Xml Schema 1.1 Requests

Hi,

I am currently working using XML Schema to define maximally rigorous market
message schemas for the electricity market in Ireland. In the course of this
work, we regularly need to represent specific time periods (i.e. a specific
duration in time occurring at a specific date/time) as atomic data items.

The ISO8601 standard from which XML Schema derives its datatypes does
document a standard representation for "specific time period" using the
start date/time, followed by a "/" as a time period indicator, followed by
either an (exclusive) end date/time OR a time-period.

e.g.

	2002-11-20T12:45:00.000/2002-11-20T13:00:00.000

or
	2002-11-20T12:45:00.000/PT15M

represent the 15 minute time period beginning at 12:45pm on the specified
date.

Although XML Schema 1.0 includes "dateTime" and "duration" built-in
data-types, there is no way of expressing a specific time period as a single
element/attribute. I would like to suggest that a "dateTimePeriod" datatype
be added to the built-in datatypes, with the obvious specification
constraints that:
	the starting (and ending, if specified) date/time parts be valid
according to normal "dateTime" rules
	in the first form, the ending dateTime must not be less than the
starting dateTime
	in the second form, the duration part must be valid according to
normal "duration" data-type rules

It is debatable whether it should be possible to omit the second part,
indicating a specific time period (as distinct from an instant in time)
whose duration is either defaulted in the context, or specified elsewhere
(e.g. a standalone "duration" elsewhere in the schema).

More generally, we would also like to see more extensive data validity
specification capabilities added to XML Schema (e.g. the best of Schematron,
Relax NG, etc., including the ability to specify more user friendly
validation error message texts.

Keep up the good work


Regards,

Brendan McMahon
ESB



* ** *** ** * ** *** ** * ** *** ** *
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed.
Any views or opinions presented are solely those of the author, and do not 
necessarily
represent those of ESB.
If you have received this email in error please notify the sender.

Although ESB scans e-mail and attachments for viruses, it does not guarantee
that either are virus-free and accepts no liability for any damage sustained
as a result of viruses.

* ** *** ** * ** *** ** * ** *** ** *

Received on Monday, 25 November 2002 20:46:05 UTC