configurations, variants, and versions

Dylan,

<It seems to me that you are using the terms version, variant and =
configuration in some strange ways.

e.g.
>Accessing multiple variants -- for an individual object, isn't that
>done just by accessing the appropriate member of a container?  That
>is, if /foo/bar names the containers holding all versions of 
document
>bar, then /foo/bar/13 might be version 13.

Here you are confusing version with variant.>

Yes. You are right.

<I think when you talk of configurations (at least from what has been 
=
said in this email) you are actually talking about a logical group of 
=
variants (e.g. A Word Document (source), its HTML and PDF renditions) 
=
which are all semantically equivalent. As far as I can tell this is 
what =
we refer to as the variants of a resource we just don't yet have a 
name =
for the group as a whole.>

Let me try to clarify. My earlier note actually attempted to talk 
about configurations and versions. As I was trying to say in the 
earlier message, a configuration is a named collection of versions of 
objects, which are somehow semantically consistent as a set. We need 
a way to deal with configurations and I was trying to raise the issue 
w.r.to configurations while the discussion was centered around 
identifying an approach to deal with a conceptually similar but 
different problem - that of variants. In particular, I was raising 
objections to note sent by Jim to my note about 2 months ago about 
concerns I had with respect to the draft specification that was 
posted then. Hope this clarifies the situation.

However, variants (alternates is another term used for vairants in 
other domains) are a different topic and need to be dealt with also.

In my mind, variants and configurations are independent because any 
version of any object can belong to a configuration while variants 
are typically about variations of  one version of one object. While 
they share some of the same conceptual issues, they are used 
differently. For example, there is the question of what happens to a 
configuration when one of the versions that belongs to the 
configuration evolves. Same question also applies to variants. What 
happens to the versions of variants belonging to a group when one of 
the variants evolves (i.e., goes to the next version). These problems 
are conceptuall similar, but their use in variants as compared to 
configurations will lead to different implementation answers 
(particularly at the protocol level).

Also, btw, in non document othering domains the ways of dealing with 
different variants (and configurations) are well developed and 
whatever solution we come up with here should not constrain those 
domains unnecessarily. In particular, in the domain we are interested 
in i.e., Product Data Management (PDM), variants (called alternates 
there) have an associated need for what is called effectivity 
management.

For example, in PDM,  alternates are used to identify different parts 
that might be used insted of the original part. This gives the 
factory flexibility to swap parts when needed.

Furthermore, configurations and alternates have "effectivity 
properties" (called effectivity management). So, for example, a Ford 
Escort configuration with left hand  side steering wheel assembly is 
effective in Japan while a different configuration with right hand 
side steering wheel assembly is effective in U.S. However, for 
product release a top level configuration (e.g., Ford Escort Model 
1997) might be used to coordinate product releases across different 
countries.  Due to this, folks have to worry about which 
configuration is effective in which country. This also affects parts, 
their units (inches vs. cms for example) and alternates.

Sankar

P.S: My fear is that the current focus on document authoring in this 
group is going to restrict implementation of scalable solution in 
other Distributed Authoring and Versioning domains. I have been 
repeatdly raising this top level objection and at the same time also 
pointing to specific issues that should be resolved (particularly 
w.r.to configurations and extensibility) before we finish up. 
Otherwise, it makes it difficult (not impossible) for folks like us 
to build inter-operable products based on WEB-DAV protocol in domains 
such as PDM.

Received on Monday, 1 September 1997 19:01:48 UTC