| Re: infrastructure_V094_13 [message #51 is a reply to message #49] |
Fri, 28 November 2003 12:15   |
Matthias Hengartner
Messages: 57
Registered: August 2003
|
Member |
|
|
Hello again...
> What did you mean by "otherID"? Is it meant to replace the attribute
> "connSwitchID"?
How do you say "jein" in English? "Yo" or "Nes"?!
But seriously: I named this attribute "otherID" because it refers either to
a connection or to another switch element. I thougt if I named it "connId"
oder "connSwitchId", it would be a little bit confusing. But if we rename
it, it'll be fine with me.
Alternatively, we could remove this attribute and introduce an attribute
"connId" for junctions and "connSwitchId" (or "otherSwitchId") for
crossovers.
By the way, what do you think about the "location" of the new
<connection>-element in the scheme?
Alternatively, we could also place it in <trackData>.
> Here we will have to define how to use them. Keeping the old IDs implies
> once again the danger of redundant information. Is the "uniqueID" meant to
> become a required attribute later on?
Yes, you're right; using two different types of IDs implies redundance. But
the old IDs are meant to refer to reality and are probably not globally
unique (e.g. the ID of a operation control point is probably "only" unique
within one specific country). Nevertheless we should keep them in the scheme
for informational purposes (like other attributes, e.g. the name).
I think, "uniqueId" will become a required attribute later on.
Please have also a look on the following quotation from Joachim Büchse,
25.9.03:
--- begin quotation
> Hence my suggestion is:
>
> RailML should use IDs (attribute with the name ID) for main elements
> like track, line etc. IDs MUST be of type string. IDs SHOULD have a
> minimal length of 8 and a maximal length of 32 symbols. Applications
> SHOULD create IDs that are globally unique. Applications SHOULD preserve
> IDs when importing and reexporting a data set with RailML. The content
> of IDs MAY be arbitrarily choosen but SHOULD NOT be semanticly
> interpreted by an application. IDs SHOULD NOT be used to order elements.
>
> Please note: I do not suggest the IDs should be used to replace
> attributes like lineId, trackId, etc in the current schema [except where
> thoose are only used to reference elements].
--- end quotation
The remaining question is, which of those two types of IDs should be used in
which cases. If there should be the possibility to enter an ID (for
reference, which might be the case for "ocpId" of <crossSection>), it surely
would not be practical to use "uniqueId". "uniqueId" should stay an
attribute for datastructure-interal use only.
Best regards,
Matthias Hengartner
|
|
|
|
Members
Search
Help
Login
Home
