| Re: roles [message #1130 is a reply to message #1129] |
Mon, 12 November 2012 11:20   |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
> My proposal:
>
> New container element in the "Common part" <companies> with specified
> child elements that may be referred from within the <trainPart>.
>
> <railml>
> <metadata> ...
> <companies>
> <vehicleOperator id="vo1" name="" startDate="" endDate=""/>
> <vehicleManufacturer id="vm1" name=""/>
> <infrastructureManager id="im1" name=""/>
> <railwayUndertaking id="ru1" name=""/>
> <concessionaire id="cc1" name=""/>
> <contractor id="cr1" name="" role="catering" subLevel="1"/>
> <otherCompany id="" name=""/>
> </companies>
> ...
> <timetable...>
> ...
> <trainPart...>
> ...
> <companyBinding>
> <railwayUndertaking ref="ru1"/>
> <contractor ref="cr1"/>
> </companyBinding>
> </trainPart>
> ...
> </timetable>
> </railml>
>
> Any comments appreciated.
>
Thanks for this proposal, it looks good. I would not use the term
"company", though, as often, organizational units (within some company,
or public authority) are meant. So I would prefer <organizationalUnit>,
<otherOrganizationalUnit>, etc.
I'm not sure whether we really need a hierarchical model of roles. I
would be happy if only the <otherCompany> gets a role - attribute and
leave the contractor without.
I'm also not sure about the dates. If these dates are anchored in the
common part, I would understand that the /licence/ or similar of those
units is restricted. But probably, what one wants to restrict is the
/binding/. So I would move the restriction to that location.
Best, Andreas.
> Kind regards...
> Susanne
>
|
|
|
|
Members
Search
Help
Login
Home
