MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "TT:activationTime",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "2099": {
                "pageid": 2099,
                "ns": 0,
                "title": "Rollingstock",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "{{navi}}\n==Rollingstock (RS)==\n[[RS:rollingstock|RS root element]] \u2014 [[RS:UseCases|RS use cases]] \u2014 [[#Documentation|Concepts & examples]]\n=== General Information ===\n\nThe rollingstock subschema is part of the complete {{site|https://www.railml.org|railML}} schema providing a data structure in XML language for the exchange of railway specific data.\n\nThe rollingstock schema provides container for all data about any kind of rail vehicles including locomotives, multiple units, passenger and freight wagons. The second part of the schema enables the combination of single vehicles to formations as a fixed composition within a train or an entire train. The root element is always {{CO:Tag|railml}}, thus it is even possible to combine data of rolling stock with those of other {{rml}} schemes within one file. The main element for this schema is {{RS:Tag|rollingstock}}, which is the root for data about any rolling stock.\n\nIt is intended to use this data schema for vehicle management as well as for detailed run-time calculations. Depending on the purpose only the {{RS:Tag|vehicles}} branch of the data tree may be populated or the {{RS:Tag|formations}} branch appears or both of them. The {{RS:Tag|vehicles}} branch contains all data related to single vehicles. However, there are data, which are mainly used in relation to a composition of vehicles. Therefore the {{RS:Tag|formations}} branch is used to reflect the characteristics an entire train or a composition of vehicles within a train.\n\nThe Rollingstock schema comprises the following features:\n\n* separate parts for vehicles and for train parts or complete trains\n* possible specification of vehicle families and individual vehicles using the common features of the family\n* different level of detail for data\n:# vehicle as black box (with respect to dynamic characteristics) with only mean values\n:# vehicle as black box (with respect to dynamic characteristics) with curves for particular values being variable within the operating range\n:# vehicle as white box with details about the internal propulsion system\n* vehicles with motive power, for passenger or freight use\n* combination of vehicles to formations, i.e. train parts or complete trains\n\nPlease visit the {{site|https://www.railml.org|{{rml}} Website}} for more detailed information about the Rollingstock subschema or send an [mailto:coord@rollingstock.railml.org email] to the coordinator of the subschema.\n=== Documentation ===\nFor more information please refer to the following pages:\n* {{RS:Tag|rollingstock}} \u2014 documentation of the main element\n:* [[:Category:Rollingstock_Elements|Rollingstock Elements]] \u2014 overview off all XML elements found in the rollingstock subschema\n* [{{uml|RS}} UML visualization of the current {{rml|2}} RS subschema]\n<!--* Rollingstock Concepts \u2014 explanations of some basic modelling concepts to this subschema (planned)-->\n* [[RS:UseCases]] \u2014 a collection of [[Dev:Use_cases|use cases]] for the RS-subschema\n*{{site|https://www.railml.org/en/user/exampledata.html|Examples}} \u2014 collection of examples provided by the {{rml}} partners\nAll elements in the Wiki are documented with the elment name and the prefix of their subschema (''RS:'' for timetable) \u2014 e.g. the wiki documentation for {{RS:Tag|vehicle}} is found here: [[RS:vehicle|https://{{thiswiki}}.railml.org/wiki/RS:vehicle]]\n\n{{interwiki}}"
                    }
                ]
            },
            "2032": {
                "pageid": 2032,
                "ns": 0,
                "title": "TT:UC:Ausschreibungsfahrplan",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "Use case / Anwendungsfall / Sc\u00e9nario d\u2019utilisation:\n\nA timetable for a competition (call for proposals) Ausschreibungsfahrplan; ???\n\n\nDescription / Beschreibung / Description\n\nThe use case describes a timetable which is transferred\n\n    from an authority issuing the invitation to bid\n    to any potential bidder \n\nwith the aim to describe which timetable is asked for in the competition, i. e. the amount of trains, their routes and (regular) operating days and possible any other properties of the trains such as services or minimum seating capacities.\n\nThe background behind such a data exchange with {{rml}} files is, especially at competitions of large production amount, it will be easier for the bidders to reproduce the timetable in their own software systems. This allows a quicker calculation e. g. of the number of vehicles necessary or, at least, the price. Time consuming and potential faulty manual transcription of the timetable shall be avoided. The usage of {{rml}} for such a data exchange (instead of more special file formats) shall keep this procedure transparent and non-discriminating.\n\nThe main intention of the use case is passenger traffic since the number of trains and the extent of the timetables is typically more complex than in freight traffic. But it may also be used for freight traffic.\n\n\nData Flows and Interfaces / Datenfl\u00fcsse und Schnittstellen / Flux de donn\u00e9es et interfaces\n\nThe use case covers a one-direction data exchange only; a possibly offered timetable (from bidder to authority) is not part of this use case.\n\nThe use case covers the exchange of the following data in general:\n\n    <train> elements with their routes and timings (in associated <trainPart> elements),\n    <ocp> elements to describe the references from the trains to the infrastructure (stations). \n\nThere are several degrees of complexity of which the use case may be used:\n\n    with minimum infrastructure (general <ocp>s only) or all necessary infrastructure (<lines>, <track>s, gradients, speeds a. s. o.),\n    with or without <vehicle>s and <formation>s,\n    with or without a timetable period,\n    with or without circulation plans. \n\nThe following description refers to the usage of {{rml}} model 2.2 for this use case since there is no version 3 in use at time of writing.\n\nInfrastructure\n\nFrom the current experience (as of 2015), it is typical that {{rml}} files of that use case contain a minimum infrastructure only. The main reason for that may be that normally the authority issuing is not the infrastructure manager. Nevertheless, general infrastructure data are quite published in a competion as a kind of \u201cpassing through\u201d issue from the infrastructure manager(s) through the issuing authority. So it may be that they are included in the same {{rml}} with the timetable. With the advent of national infrastructure registers, it is likely that such registers are referred or extracted in another, say, {{rml}} file.\n\nAnyway, <ocp>s must be included since without them no {{rml}} <timetable> file is possible. <lines> and <tracks> are included if necessary to exactly describe the train\u2019s route in complex infrastructure situations (areas of parallel lines). More infrastructure data (gradients, speed a. s. o.) are rather a matter of the previous paragraph.\n\nIt shall be assumed that a timetable of this use case is checked by the infrastructure manager(s) in advance and therefore planned in detail.\n\nIf more infrastructure is included, its scope is macroscopic.\n\nTimetable period\n\nTypically there is no <timetablePeriod> for timetables of this use case. The timetable is valid not for a certain but a number of years which are not specified in the {{rml}} file.\n\nThe <operatingPeriod>s of the trains have regular weekdays only with no special operating days and no certain date references. The timetables are typically not planned with regard to public holidays or such; the amount of train kilometers a. s. o. is only calculated on a statistic basis (flat number of operating days, statistic year).\n\nHowever, there may be a <timetablePeriod> defined for one year as a place-holder for all the years. This is common practice if seasonised trains operate, e. g. school trains or summer-only trains.\n\nTheoretically, there may be a very long <timetablePeriod> for all the years the timetable shall be valid. Since this leads to very long bitmasks of <operatingPeriod>s with normally no additional benefit it is not common and not recommended.\n\n<vehicle>s and <formation>s\n\nIf the supply of vehicles is component of the competition, often there are neither vehicles nor formations given with the timetable data because this is treated necessary for non-discrimination. However, for practical reasons, normally there is a master vehicle at least for run-time calculation. This is often the slowest acceptable vehicle and may be a theoretical one (a coefficient of power and mass only). It is common to publish this master vehicle with the call for tenders. If the vehicles are allocated there is no reason to exclude them from the timetable.\n\nSo, there may or may not be <rollingstock> data in the {{rml}} file.\n\nCirculation plans\n\nTypically the construction of circulation plans is up to the bidder, so no circulation plans are included. This is likely to be because neither the type (and capacity) of the vehicle(s) nor the location of the depot(s) are known in advance. On the contrary, and even if the vehicles are allocated, circulation plans are expected from the bidders to show their competence.\n\n\nReferences to other data models or outside-world / Referenzen zu anderen Datenmodellen einschl. Nicht-Software-Daten / ???\n\n    In any case, <ocp>s refer to one or more national register(s) of stations or other operational places by their <designator> elements. So, it is mandatory to use at least one <designator> with a pre-defined register. For Germany, this is, as of 2015, register='RL100'. \n\n    If <line> elements are included, it must be possible to identify the <line> elements with the lines of the corresponding infrastructure manager. This can be done directly from attributes of the <line> elements or indirectly from attributes of the <track> elements. For Germany, as of 2015, the <line>.code attribute has to contain the VzG-Streckennummer, so it must be a 4-digit integer value. \n\n    If <track> elements are included, it must be possible to identify the <track> elements with the tracks of the corresponding infrastructure manager. This can be done by a unique attribute of the <track> elements (like code) or by a direction of the track in conjunction with the <line>s. For Germany, if <track> elements are included, also <line> elements have to be included. Each <track> element must be part of (referenced by) exactly one <line> element. \n\n    With regard to neutral (non-discriminating) data, the <category> elements do not necessarily need to refer to actual train categories of a certain operator. They can refer to categories of the corresponding infrastructure manager if applicable - or they can be missing or even contain \"phantasy\" categories. For Germany, since the kind of operator can still be deduced from the DB Netz\u2019s category codes, it is likely to have \"neutralised\" categories. If <category>s are used, their attribute code has to be unique. \n\n    Since the timetable is more a virtual than an actual one, <train> elements are not necessarily to be identified externally. So, train codes nor numbers need not to be given. However, for reasons of practicability, it shall be possible to uniquely identify a train. For Germany, operational trains need to have a unique set of the attributes trainNumber, additionalTrainNumber, and scope (default {{rml}} rules). Commercial trains need to have a unique trainNumber (additionalTrainNumber and scope do not apply here). \n\n\nInterference with other {{rml}} schemas / Interferenz mit anderen {{rml}}-Schemen / Interaction avec autres schemas {{rml}}\n\n    <infrastructure> (mandatory)\n    <rollingstock> (optional) \n\n<infrastructure> is referenced\n\n    from <ocpTT>.ocpRef to <ocp>.id (mandatory),\n    from <sectionTT>.lineRef to <line>.id (optional),\n    from <sectionTT>.<trackRef>.ref to <track>.id (optional)\n    from <trainPartSequence>.<speedProfileRef>.ref to <speedProfile>.id (optional) \n\n<rollingstock> is referenced\n\n    from <formationTT>.formationRef to <formation>.id (optional)\n    from <rostering>.formationRef to <formation>.id (optional)\n    from <rostering>.vehicleRef to <vehicle>.id (optional) \n\n\nCharacterising Data / Charakterisierung der Daten / Caract\u00e9risation des donn\u00e9es\n\nThis section serves to specify the required data regarding certain aspects.\n\nHow often do the data change (update)?\n\n    static (not changing)\n    in cases of error-corrections: weekly .. daily in rare cases during a short period (of submission); will probably be handled by a complete data renewal (overriding) \n\nHow big are the data fragments to be exchanged (complexity)?\n\n    infrastructure: medium (region), macroscopic\n    timetable: medium (region; several up to some hundred trains); operatingPeriod: tiny (one or none)\n    rolling stock: small (none, one or a few vehicles and formations) \n\nWhich views are represented by the data (focus)?\n\nLong term planning (starting typically 1..5 years in future with a duration of typically 3..15 years)\n\nWhich specific timetable data do you expect to receive/send (elements)?\n\nUsed elements (extract - more is allowed):\nElement \tMandatory \tRemarks\n<infrastructure>.<tracks>.<track>.<trackTopology>.<trackBegin>.<macroscopicNode>.ocpRef <infrastructure>.<tracks>.<track>.<trackTopology>.<trackEnd>.<macroscopicNode>.ocpRef <infrastructure>.<tracks>.<track>.<trackTopology>.<crossSections>.<crossSection>.ocpRef \t*1 \tused to define the conjunction between <track>s and <ocp>s if <track>s are included\n<infrastructure>.<trackGroups>.<line>.code \t*2 \tused to identify a line of the Infrastructure Manager(s)\n<infrastructure>.<trackGroups>.<line>.infrastructureManagerRef \t\tused to identify the Infrastructure Manager(s) at least if more than one is involved\n<infrastructure>.<trackGroups>.<line>.<trackRef>.ref \t*2 \tused to define the conjunction between <line>s and <tracks>s\n<infrastructure>.<operationControlPoints>.<ocp>.<designator>.register / .entry \tx \tused to identify an <ocp> of the Infrastructure Manager(s)\n<timetable>.<timetablePeriods>.<timetablePeriod>.startDate / .endDate\n<timetable>.<timetablePeriods>.<timetablePeriod>.<holidays>.<holiday>.holidayDate\n<timetable>.<operatingPeriods>.<operatingPeriod> \tx\n<timetable>.<operatingPeriods>.<operatingPeriod>.timetablePeriodRef / .bitMask \t\tmust be used if a <timetablePeriod> is included only\n<timetable>.<operatingPeriods>.<operatingPeriod>.<operatingDay>.operatingCode \tx\n<timetable>.<operatingPeriods>.<operatingPeriod>.<operatingDay>.<operatingDayDeviance>.operatingCode / .holidayOffset / .ranking\n<timetable>.<operatingPeriods>.<operatingPeriod>.<specialService>.type / .startDate / .endDate \t\tcan be used if a <timetablePeriod> is included only\n<timetable>.<categories>.<category>.code \t\tused to identify a train type or category of the Infrastructure Manager(s) or a virtual one\n<timetable>.<trainParts>.<trainPart> \tx\n<timetable>.<trainParts>.<trainPart>.<formationTT>.formationRef\n<timetable>.<trainParts>.<trainPart>.<formationTT>.<passengerUsage>.<places>.category / .count \t\tmay be used to define a minimum necessary seating capacity\n<timetable>.<trainParts>.<trainPart>.<formationTT>.<passengerUsage>.<service>.category / .count \t\tmay be used to define a minimum acceptable service\n<timetable>.<trainParts>.<trainPart>.<operatingPeriodRef> \tx\n<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.ocpRef \tx\n<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<times scope='scheduled' \u2026> \tx\n<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<times scope='scheduled'>.arrival / .departure> / .arrivalDay / .departureDay \t(x) \tmandatory in context as usual\n<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT>.lineRef \t\tmust be used if <line>s are included\n<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<sectionTT>.<trackRef>.ref \t\tmust be used if <track>s are included\n<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.commercial / .stopOnRequest\n<timetable>.<trainParts>.<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.<stopTimes>.minimalTime \t(x) \tmandatory in context for ordered traffic stops\n<timetable>.<trains>.<train type='operational'> \tx \teach <trainPart> must be covered by exactly one operational train\n<timetable>.<trains>.<train type='commercial'> \t\tused if operational trains are not sufficient to describe the timetable (especially with train coupling and sharing)\n<timetable>.<trains>.<train>.trainNumber / .scope / .additionalTrainNumber\n<timetable>.<trains>.<train>.<trainPartSequence> \tx\n<timetable>.<trains>.<train>.<trainPartSequence>.sequence \tx\n<timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef> \tx\n<timetable>.<trains>.<train>.<trainPartSequence>.<trainPartRef>.ref / .position \tx\n\n\n*1 mandatory if <track>s are included\n*2 mandatory if <line>s are included\n\n\nAdditional requirements\n\nEach <trainPart> must be covered by exactly one operational train. If commercial trains are given, each <trainPart> must be covered by exactly one commercial train.\n\nIf seating capacities or services are defined at <trainPart>s and at <formation>s or <vehicle>s, later defined values override earlier defined values in the meaning of concretising. Formations override vehicles, train parts override formations. In this special use case, the values at <trainPart>s shall be treated as minimum necessary values and the values at <formation>s or <vehicle>s as planned capacity of the master vehicle(s).\n\nIf minimum seating capacities differ for certain operating days (at the same train and route section), the corresponding train has to be split in several <trainPart>s with parallel route and disjunctive operating days. Each <trainPart> can refer to a different seating capacity. All these <trainPart>s have to be joined in the corresponding <trainPartSequence>s.\n\n(This procedure also applies to other properties of trains and train parts. Train parts with disjunctive operating days do not have to be mixed with coupled train parts, which apply to train coupling, sharing and \"strengthening\". See corresponding descriptions for further information.)\n\n\nOpen Issues\n\n    Usage of tTimeScope=\"earliest\" / =\"latest\" instead of or additionally to =\"scheduled\".\n    Defining (planned and/or expected) connections between the <train>s involved and also to other (external) <train>s. \n\n\nImprovements for further versions\n\n1)\nTo be exactly, as of {{rml|2.2}} there is no distinction between values which are minimum necessary and which are planned. There may be a difference between them especially in the use case of timtables for competitions. This applies to\n\n    arrival / departure / run times (planned run time with a master formation vs. maximum accepable run time with any other formation)\n    seating capacities (planned seating capacity with a master formation vs. minimum accepable seating capacity)\n    connections \n\nand possibly more.\n\n2)\nAt least until {{rml|2.2}} it is not clearly defined how two <trainPart> elements in succeeding <trainPartSequence>s must be chained to model a running through service (group of vehicles). One approach is to chain all <trainPart> elements with the same key (code, name, etc.) in an order whereat the last referenced <ocp> of the current <trainPart> is the same as the first <ocp> of the following <trainPart>. (This order can already be deduced from commercial train elements.) A better modelling for this aspect is, in the author\u2019s opinion, to use the concept of commercial trains in a different way than currently described in Wiki: Each commercial train should model exactly one sequence of <trainPart> elements. Today it may contain several \"parallel\" sequences of <trainPart> elements at the same time, which makes it impossible to figure out which <trainPart> elements of two succeeding <trainPartSequence>s must be linked together.\n\n3)\nThe redundancy of repeated arrival and departure times of coupled <trainPart>s shall be avoided e. g. by extracting \"itineraries\" (refactoring)."
                    }
                ]
            }
        }
    }
}