NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Mike,
> This question came up today at the NASA briefing, when we were talking
> about the netCDF 4 project. There was a weak but immediate and negative
> reaction to using time as a proxy for creation order. The reason given was
> that many applications would want to use the creation time as an attribute,
> but that the times used would not necessarily give the same ordering as
> creation time because different times might be relative to different time
> zones. I have a feeling there were other cases, given the reaction people
> had.
>
> Of course this could only happen if people were allowed to change the
> "creation time." And one could also argue that creation time is a
> different attribute -- it's the time the link was created, not the time the
> data was collected. But I have a feeling this would just lead to confusion.
>
> So at best, I think there is concern that this could led to confusion. I
> tend to agree.
Ok, I think we've heard enough customer push-back on this that we ought to
provide both options and allow people to choose which they'd like. Here's a
list of the fields that I'm planning on storing on storing for each link:
- Name (indexable, must be unique, modifiable)
- Creation time (indexable, may be non-unique, modifiable)
- Creation order (indexable, unique, monotonicly increasing, non-modifiable)
- Character set (i.e. ASCII, UTF-8, etc.) (non-indexable?, non-unique,
modifiable)
- Object address/link target (for hard/soft links) (non-indexable, may be
non-unique (for multiple links to same object), modifiable?)
Applications can determine which of the three indexable fields they'd like
to have an index maintained for with a group creation property. They will
choose an index for iteration, etc. with a group access property.
Quincey
>
> Mike
>
> At 10:16 AM 4/19/2005, Quincey Koziol wrote:
> > > Quincey Koziol <koziol@xxxxxxxxxxxxx> writes:
> > >
> > > > I was planning on including a hidden field to disambiguate
> > objects that
> > > > were created at the same time, so this wouldn't happen. Since there's
> > > > no
> > > > advantage to using a creation order field instead of using the
> > creation time
> > > > when determining the n'th object inserted into a group (when
> > factoring deleted
> > > > objects into the equation), I'm still leaning toward using a time
> > instead of an
> > > > index for this purpose. Using the time provides the same
> > functionality and
> > > > adds information as well.
> > > >
> > > > I'm still somewhat split on the issue however and would welcome
> > persuasive
> > > > arguments in favor of one mechanism or the other. :-) I'm also
> > thinking about
> > > > including both fields (creation order and creation time) and allowing
> > users to
> > > > create an index on either, to suit their particular needs...
> > >
> > > Quincey,
> > >
> > > What happens is a machine with an inaccurate time adds a variable to a
> > > dataset?
> >
> > It'll get the "wrong" creation time and inserted in the index
> >appropriately, as you'd expect. I don't think this is a major problem
> >though,
> >because I don't think that most files will get edited on multiple machines in
> >a very short timeframe.
> >
> > Quincey
>
> --
> Mike Folk, Scientific Data Tech (HDF) http://hdf.ncsa.uiuc.edu
> NCSA/U of Illinois at Urbana-Champaign 217-244-0647 voice
> 605 E. Springfield Ave., Champaign IL 61820 217-244-1987 fax
>
netcdf-hdf archives: