| Re: ocp's/stations and their properties [message #347 is a reply to message #344] |
Sat, 01 September 2012 12:12   |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Dirk & everyone interested,
>>> So, my suggestion would be:
>>> - to define an optional attribute ‘parentOcpRef’ (=tGenericRef) of an
>>> <ocp>.
>
>> However, your question brings it to the point: Do we need an explicit
>> <ocpGroup> or may we reference from one <ocp> to the next/parent
>> <ocp>? What do others think about this question regarding their usage
>> of <ocp>?
>
> It seams to me that an optional attribute ‘parentOcpRef’ (=tGenericRef)
> of an <ocp> is the simplest way to allow the desired function: No
> additional structures, no 'ref's to more than one target list, direct
> (cascaded) cross-references from a train to it's ocp's, more flexibility.
And that is the way, how we will do it with railML 2.2. An <ocp> may
refer to its one and only parent <ocp> using the new optional attribute
'parentOcpRef' of type tGenericRef.
This requires the following changes within infrastructureTypes.xsd (c.f.
trac ticket [1]):
<xs:complexType name="tOperationControlPoint">
<xs:complexContent>
<xs:extension base="rail:tElementWithIDAndName">
...
<xs:attribute name="parentOcpRef" type="rail:tGenericRef">
<xs:annotation>
<xs:documentation>references the one and only parent ocp of
this ocp</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
However, I still think that concerning the overloading of attributes, we
should follow the concept that the attributes of a referenced
"parentOcp" should be overwritten by corresponding attributes from the
referencing <ocp>.
Regards
[1] https://trac.assembla.com/railML/ticket/153
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
Members
Search
Help
Login
Home
