| Re: request for an attribute for the Infrastructure Manager of a line [message #497 is a reply to message #488] |
Mon, 03 December 2012 21:55   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Dirk,
Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
> Am 03.12.2012, 11:45 Uhr, schrieb Susanne Wunsch <coord(at)commonrailmlorg>:
>
>> I would propose the following structure for the XML file:
> ...
>> <infrastructureManagerCode id="d1e3">
>> <version>
> ...
>> <rail:line id="l1" infrastructureManagerCode="EIB">
>> <rail:trackRef ref="t1"/>
>> </rail:line>
>
> As far as I see, the /id/ and /infrastructureManagerCode/ are used
> redundantly. Which one of both attributes is the real reference and
> which one is "for information only"?
Not "redundantly", but currently the 'id' of the
<infrastructureManagerCode> in the separate XML file is not used at all.
We thought about using the "id" value instead of the "code" value, but
that would mean, that any software which reads a railML file without
knowledge of the separate "list-XML-file" gets _no information_ for this
attribute.
> I think <trackRef /ref/> is the real reaference and
> /infrastructureManagerCode/ is "for information only".
The 'trackRef' is the "real information" for grouping the tracks into
lines for the railML file context. The 'infrastructureManagerCode' is
the "real information" for defining the "owner" of the defined 'line'.
I don't see any redundancy here. If the importing software already has
some knowledge about lines, their tracks and its infrastructure manager,
it has to check the consistency of the railML data.
> But this
> - is different than in the past (where there was no /ref/ at a line),
The concept of 'trackRef's in the 'line' element was introduced with
railML 2.0.
> - is confusing because not self-explaining.
Please help me out, I don't see the confusion yet. But I know, I'm
sometimes a bit blind regarding the semantics of railML constructs.
> At least, is not practical because in cases when a software knows only
> the abbreviation of the IM, it is not known whether one should simple
> use the attribute <line /infrastructureManagerCode/ > or one should
> create an element <infrastructureManagerCode> for only this code.
* If the abbreviation of the IM matches one "currently valid" "code" in
the XML-list-file, all is fine. This abbreviation should be taken for
the attribute "infrastructureManagerCode" in the "line" element.
* If the "string" look up fails, the abbreviation may be defined in the
XML-list-file in a slightly different way, eg. "DB-Netz" vs. "DB Netz
AG". Then the XML-list-file entry "code" is recommended to use for the
attribute "infrastructureManagerCode" in the "line" element.
* If the look up fails at all, because this IM is currently not
registered at the XML-list-file this "RFE (request for enhancement)"
should be sent to the railML infrastructure coordinator in order to
add this value. The proposed new abbreviation for the IM should be
used for the attribute "infrastructureManagerCode" in the "line"
element.
> At least, if you decide to do it anyway, please say that the addresses
> and such (what Andreas suggested) is included in
> <infrastructureManagerCode><version>.
I see the addresses as some kind of contact data. I don't want to host
them at railML. It's more or less a hint for the railML-file-consumer
whom to contact in case of any questions. It may be a special personal
contact information, eg. a person responsible for a single region with
its mobile number.
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Members
Search
Help
Login
Home
