| Re: Some problems with/questions about the infrastructure schema... [message #85 is a reply to message #84] |
Wed, 16 June 2004 17:49   |
Volker Knollmann
Messages: 32
Registered: October 2003
|
Member |
|
|
Wolfgang Keller wrote:
> 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.
Do you speak of reserved keywords within your database-dialect (SQL,
etc) or your programming language? If so, it should always be possible
to escape such keywords with single / double /triple quotes, backslash
and other means. And regarding SQL: I don't think that a statement like
SELECT * from switches WHERE type="ordinarySwitchRight"
causes problems, does it?
> It would be best imho if all identifiers were unique
> within the entire schema in order to avoid confusion.
Hmmm, I would prefer the opposite syntax. For example, I would
appreciate a common attribute "elemID" for all elements. Right now, we
have "ID", "elemID", "ocpID", "connectionID", etc. "elemID" is used in
many children of <trackData>, why not everywhere?
> 2. Why are the <x>ChangeType definitions not based on the corresponding
> <x>Type definitions (by reference, inclusion of a subelement or whatever
> method)?
IMHO, this is a good suggestion for the sake of consistency. A
xChangeType could be a combination of xType and something like
"positionType", which encapsulates the typical attribute pos, absPos,
dir and (occasionally) a track- and line-ID.
> 3. The part of the schema about connections appears to be especially
> "unstable" at the moment.
I plead "not guilty", your honor! ;)
BTW: I spent the last days implementing a fictional example track in
RailML and I came across a bunch of missing elements, attributes and
structures. I will create a summary of my "problems" and post it to this
newsgroup in the next days.
> 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...?
What exactly do you mean? A formal description like ER-Diagrams or similar?
Imho XML is the best choice for our needs:
* structured and hierachical
* extensible without compatibility problems
* human readable
* can be edited with a simple editor
* supports encodings and complex character sets, but...
* ... can be used with 7-bit ASCII as well (works ALWAYS!)
* no bothering about linefeed, newlines and special characters when
exchanging data between different platforms
* can be formaly validated used DTDs or XSDs
* easy to parse, libraries available for every language and platform
* not proprietary at all
I agree, that due to a certain redundancy within the file (opening /
closing tags, ...) the file size is not optimal.
But for the transmission over bandwidth- or volume-critical connections,
you can apply $FAVOURITE_COMPRESSION_UTILITY to your data and you should
get satisfying results...
Best regards,
Volker Knollmann
|
|
|
|
Members
Search
Help
Login
Home
