| Re: infrastructure_V094_13 [message #53 is a reply to message #51] |
Fri, 28 November 2003 15:41  |
nfries
Messages: 6
Registered: November 2003
|
Junior Member |
|
|
Hi Matthias,
>> 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.
Would it not be best to unify all possibilities of connecting two tracks
i.e. always use the <connection> element? I propose to leave it like that
except add the attribute "connDir" and change the type of "connID" to
"uniqueIdType". As well, we do not really need both - "connId" and
"uniqueID" - do we?
Additionally it will be linked to <junction> and <crossover> which allows
us to cancel "branchLineId", "otherID", "branchTrackID", "branchPos" and
"branchDir" inside the <switch> element.
> 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>.
No, it should be all right here.
>> 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.
I agree. Logical references should not be replaced by structural
references ("uniqueId"), although from the structural point of view it
might define the same relation.
Have a nice weekend,
Nikolaus
|
|
|
|
Members
Search
Help
Login
Home
