Home » railML newsgroups » railml.common » compound values, notations
compound values, notations [message #997] Thu, 25 September 2003 16:25 Go to next message
Joachim Buechse is currently offline  Joachim Buechse
Messages: 8
Registered: September 2003
Junior Member
The RailML scheme currently uses compound values in some places. I.e.
Kilometrierung [12.123 | 123.334+1.567] or arrivalTime [hh:mm | hh:mm:ss
| hh:mm,d].

XML leaves a large degree of freedom for the definition of data types
besides the standard XMLSchema data types. It is absolutely legitimate
do define new types. From what I have seen so far it is however rather
unusual to define compound types or allow different notations for the
same semantical value.

As a general rule I want to suggest that different notations for the
same attribute value should be discouraged as end-user represantation
should be within the scope of the application not the data transfer format.


Kilometrierung uses a compound type where the second 'attribute' is
optional. While the notation is perfectly clear in a rail context it
could as well be expressed with two separate 'attributes' which avoids
the need to implement a special parser for the data type. From my
stomachs feeling this would be cleaner XML (at least it allows easier
processing with XSLT).

arrivalTime (or departureTime) allows different notations and uses a
compound value in the case hh:mm,d. The notation implies a precision of
10th of a minute. Again I would argue that it would be a cleaner XML
approach to have two 'attributes' both expressed as hh:mm:ss where
13:24,3 would be expressed as arrivalTime="12:34:30"
arrivalPrecision="00:00:10".

There are some predefined XSDSchema types expressing points in time (i.e
a single unique point in stellar time) or recurring time (ie noon).
Examples are time and timeInstant. Both use a time representation of
hh:mm:ss.ddd where ddd are milliseconds. I cant currently give a clear
recommendation whether we gain something (regarding existing toolkits)
by sticking to the same format.

Best regards,
Joachim Buechse


PS: I believe there have been detailed discussion before in which format
arrivalTime and departureTime should be expressed (ie time zones) so I
will read the protocolls and news messages before starting it again...
Semantically they seem to me like a timeInstant (GMT time on first
scheduled day) + repetition rule. Of course daylight savings time needs
some special consideration. I will have a chance to talk to the people
from Hacon in about two weeks.

--
buechse(at)ergonch, Phone +41 1 268 89 58, Fax +41 1 260 20 65
Ergon Informatik AG, Kleinstrasse 15, 8008 Zuerich, Switzerland
http://www.ergon.ch
________________________________________________________
e r g o n smart people - smart software
Correction: timeInstance meant dateTime [message #1001 is a reply to message #997] Mon, 29 September 2003 17:48 Go to previous message
Joachim Buechse is currently offline  Joachim Buechse
Messages: 8
Registered: September 2003
Junior Member
Sorry for answering to myself, I want to correct 2 misakes to avoid
confusion:

- there is no XMLSchema timeInstant type, the type I meant is dateTime
- dateTime does not NOT contain milliseconds

XMLSchema defines dateTime identical to ISO8601. dateTime and time allow
for the specification of a time zone, which makes them comparable (even
though they do not require it).

Examples:

2000-01-20T12:00:00 (no time zone, not comparable)
2000-01-20T12:00:00-13:00 (with time zone)
2000-01-20T12:00:00Z (notation for UTC ie +00:00)


The default XMLSchema types are defined and explained at:
http://www.w3.org/TR/xmlschema-2/

Deutsche Uebersetzung:
http://www.edition-w3c.de/TR/2001/REC-xmlschema-2-20010502/

Best regards,
Joachim

Joachim Buechse wrote:
> There are some predefined XSDSchema types expressing points in time (i.e
> a single unique point in stellar time) or recurring time (ie noon).
> Examples are time and timeInstant. Both use a time representation of
> hh:mm:ss.ddd where ddd are milliseconds.
Previous Topic: restrict data encoding UTF-8 or UTF-16
Next Topic: conductors/transmission lines
Goto Forum:
  


Current Time: Thu Mar 28 18:55:24 CET 2024