| Some problems with/questions about the infrastructure schema... [message #84] |
Wed, 16 June 2004 13:03  |
Wolfgang Keller
Messages: 7
Registered: May 2004
|
Junior Member |
|
|
Hello,
as a total XML illiterate I'm currently trying to build a database (ER)
schema for timetable and other operation data based on the RailML XML
schemas. During this work, I ran into some problems/unclear
points/potential improvements:
(My work is based on the files
http://www.linder-rail-consult.de/railml/docs/infrastructure /v094/Infrastructure_V095_Concept_DE_Rel1_2004-03-28.pdf
http://www.linder-rail-consult.de/railml/docs/infrastructure /v094/Infrastructure_V094_Reference_EN_2004-03-28.pdf
and
http://www.linder-rail-consult.de/railml/docs/infrastructure /v094/infrastructure_V094_18.xsd)
1. Generally I propose that identifiers such as "type", "length", "value"
etc. should not be used at all, as they risk to collide with typical
reserved keywords. It would be best imho if all identifiers were unique
within the entire schema in order to avoid confusion.
2. Why are the <x>ChangeType definitions not based on the corresponding
<x>Type definitions (by reference, inclusion of a subelement or whatever
method)? This would imho avoid redundancies as well as incoherencies. One
of these incoherencies appears to be that the electrificationChangeType
definition in the .xsd file contains vMax and isolatedSection attributes,
while the electrificationType definition does not.
3. The part of the schema about connections appears to be especially
"unstable" at the moment. When can a somehow "settled" version of this part
be expected? It also appears to me as a not-database-developer that this
part is not obvious to map to a relational schema due to the "kinks" in the
relationships, which leads to the next point:
4. Wouldn't it be useful/would it be impossible to include such
considerations as technology-independence in the design of the schema, so
that the logical structuring can also be used for plain-ASCII data exchange
(such as datagrams sent over narrow-bandwidth wireless connections etc.),
for relational databases and maybe also other implementations...?
TIA,
Best regards,
Wolfgang Keller
|
|
|
|
Members
Search
Help
Login
Home
