- From: sv <sv@hunchuen.crystaliz.com>
- Date: Mon, 1 Sep 1997 19:02:18 -0400
- To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
- Cc: "'jar@crystaliz.com'" <jar@crystaliz.com>
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