| Re: Schema version 1.00 RC1 released [message #102 is a reply to message #98] |
Wed, 29 September 2004 18:10   |
Volker Knollmann
Messages: 32
Registered: October 2003
|
Member |
|
|
Hi again,
I have a few remarks regarding the concept of the "generalElements".
First of all: I really appreciate the idea of that element.
As I explained in Berlin, we have to store various kinds of data and the
scope of that data is (currently) beyond the scope of railML. It is a
good concept to have a kind of "allround-element" / "dustbin" /
"whatever-you-like-to-call-it" to store non-railML data while still
being conformitive with the standard.
I would suggest to extend the concept of "generalElements" to other
branches of <track>. I can imagine a <generalOCSElements>-container
(child of <ocsElements>) and a <generalTrackData>-container (child of
<track>).
I give you an example:
I need to store the information, from which station / interlocking
(ocpID) a switch is controlled. One method would be to introduce an
additional attribute for <switch> (e. g. ocpRefID). Doing so, my
xml-file could never again be validated against the official scheme.
The second method would be to have an item called <generalTrackData>,
which stores arbitrary data. I would introduce a child
<switchOcpMappings> and store my information in some childs like
<switchOcpMapping switchRefID="42" ocpID="88"/>. No application except
our laboratory would care about that, the file remains valid,
everybody's happy.
Of course I see the danger that everybody stores information in the
general container instead of the "real" railML-tree. But we should try;
and maybe we can move some data structures which proove to be well
designed and accepted to the official tree in a later release.
We talked about that topic shortly in Berlin and there seemed to be some
acceptance. Since my suggestion is only a minor change to the schema
(but with major improvements), we can get an agreement on that topic
before the final freeze of V1.0.
Looking forward to your comments,
Volker Knollmann
|
|
|
|
Members
Search
Help
Login
Home
