Home » railML newsgroups » railml.common » roles
| Re: roles [message #1132 is a reply to message #1130] |
Mon, 12 November 2012 15:52   |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Andreas,
Thanks for the quick answer.
Andreas Tanner <ata(at)ivude> writes:
>> 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 go with your renaming advice.
Additionally would rename 'companyBinding' to 'contractBinding'.
> 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 had two aspects in mind, one would be a sub-contractor like already
proposed by Dirk, the other is that a 'contractor' is a really general
term suitable for all kinds of contract bindings.
So I would drop the "otherCompany" or "otherOrganizationalUnit".
> 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.
Yes, thanks for pointing this out. Let's drop the dates, too.
Kind regards...
Susanne
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
Current Time: Thu May 09 00:59:10 CEST 2024
|
Members
Search
Help
Login
Home
