Michael Lake wrote:
> Hi All,
>
> Here are some thoughts on xlink/xpointer and how they may offer an
> alternative to idrefs.
> I am not against unique id's and using idrefs. I think the equivalence
> attribute or element is a good idea and would work well. xlinking is an
> alternative road.
I have to admit that I don't completely grok xlink/xpointer yet, so I
don't have a firm opinion.
The documents I have found seem to indicate that the standards are more
provisional, and less widely implemented. Is that so?
Also, remember that whatever mechanism is used to identify stations will
need to be understood by *all* programs that read CaveXML; this is not
one of those "optional features". That means we want to uses the
simplest, widely realizable, scheme that will do the job. I don't want a
program that reads CaveXML to have to navigate a maze of optional
reference types just to find out which stations are which.
>
>> Practically, the unique station names are only useful for detecting name aliases and
>> providing references through out the CaveXML file. When reading the data of a station,
>> memory is allocated for the structure to contain the data. The physical address, pointer,
>> of that structure becomes your ID. Once the data is read in and properly sorted, the ID's
>> from the CaveXML file no longer serve any purpose.
>
> I think Garry has an important point here. With unique idrefs what will
> use them? If the editor creates them but they are not used by programs
> then that does place unneccssary data in the XML file.
The reading program *does* use them. They are needed to read the data
back in without ambiguity. It is true that once all the data is in
internal data structures, the IDs need not be used any more, but that is
true of all of the structural information in the file.
>
>
> Ralph Hartley penned...
>
>> An "Equivalence" element is still needed because there has to be a
>> nondestructive way to say that two stations are the same.
>
[proposed way to do equates snipped]
My point was that there needs to *be* an equate construct. I am not
prepared to judge the particular implementation yet. Certainly there
needs to be a way to reference a station in another file, at least in an
equivalence element. That may be an optional feature (in that there may
be some programs that don't understand it), if there is a tool for
merging files (that translates the equate into intra-file form).
>
>> The central point of my proposal is that
>> stations need to be referred to by IDREFs, which are required to be
>> unique.
>
> as above you can use xlink stuff. Thats how I was planning to handle the
> *equate used by Survex.
If it does what needs to be done (uniquely identify stations within a
file) without an undue burden, I wouldn't object too loud.
> *** NOTE That IDs must start with a letter **** so you can't have
> id="2". Thats why I have prefixed it with A.
My example was full of bugs.
> and Ralph rabbited on :-)
>
>> How do those programs work now? They must have **some** way to tell if a
>> station is new (within a file) or is the same as a previous station. If
>> they didn't, how could they do anything with the data? If station names
>> are assumed unique within (Survex) files (1, 2, 3, ...) that's fine,
>> base the station IDs on those.
>
> Survex uses *begin <some name> and *end to scope stations. So you can
> call a station what ever you like within that and use the same name
> outside that scope. The begin/ends can be nested as well.
>
>> uniqueness by prepending the file name (or a hash of it), except when
>> you know (by whatever means you use now) that two stations in different
>> files are the same (this is just one possible implementation). You can
>> keep track of file names by having one big namesystem with names that
>> combine filename and number, or separate namesystems for each file.
>
> Survex I suppose then effectively prepends those begin names to each
> station station making a heirarchical system. It would not use unique id
> refs and would require the equivalent of a nested name scoping thingy
> like what I have in my mysurvey.xml example file at my web site.
So the survex fragment:
*begin <foo>
*begin <bar>
[define a bunch of stations and shots here starting with one names "124"]
*end
*end
Could be translated to:
<NameSystem program="survex">
<Station ID="STA24327">
<StationName value="foo.bar.124"/>
</Station>
... more stations, shots, etc ...
</NameSystem>
This would be legal. But a better way (still consistent with my
proposal) might be to have a different namesystem for each scope, and
use them to keep track of the unqualified names.
<NameSystem name="foo.bar" program="survex">
<Station ID="STA24327">
<StationName value="124"/>
</Station>
... more stations, shots, etc ...
</NameSystem>
Logically this would be almost the same, but a display program might not
care that names are not unique, so it could use "124" to label that station.
Maybe it would be good to allow nested namesystems, but that might be
unneeded complexity.
> I can see that there are two ways we could go here. Using IDs and
> xlinks. Can one use both and provide two mechanisms for cave survey
> programs or would that end up forking programs in to the "unique id
> camp" and the "Xlink" camp ?
That would be bad.
> and thus spate John....
>
>> I'll still argue for a numeric ID (with some prefix) on grounds of
>> symplicity of algorithms to combine the files...
>
> I think some programs would find it useful.
And some might find it burdensome, but I have promised in private email
not to debate this point much more, it can be argued either way.
Ralph Hartley
This archive was generated by hypermail 2b30 : Mon Apr 02 2001 - 18:00:00 CEST