Mark Taylor wrote:
> On Thu, 21 Sep 2006, Pierre Didelon wrote:
>
>
>>I completly agree with your argument. Usage of (uncomplete/limited/...)
>>sofwares should not impact specifications/standard construction,
>>which must mainly be conduct by "science" use-cases.
>>Nevertheless if I have no opinion about the recursivity, I am in favour
>>of a possible usage (and so its inclusion in the schema) of ID attribute
>>on TR element. It could be use by example to "materialise" in a generic
>>VOTAble way, the cross-identification between two catalog (row by row),
>>or allow anykind of link from row to row.
>>Does it make sens?
>
>
> I'd like to see a concrete use case for this kind of thing before
> agreeing it was a good idea to introduce a TR ID attribute.
> We've considered similar things in PLASTIC messages which need
> to reference certain rows in a given VOTable, and there we just
> use row indices (0 for the first, 1 for the second, etc).
> This seems to work fine. In practice my guess is that you'd mostly
> end up giving rows IDs like "row1", "row2" etc in any case.
>
> Mark
>
You right. The only difference is that in one case, you have explicit links
that you can perhaps follow using xml mechanism and in the other case,
you have implicit joins which are not (structuraly) distinguishable from
"real" data column and are, may be, harder to "follow/retrieve".
But the final usage will be the same, so the distinction is not so
important or worth, and don't require then a standard modification?
sincerely yours
--
Pierre
Received on 2006-09-21Z15:45:00