- From: Richard Ishida <ishida@w3.org>
- Date: Wed, 7 Apr 2004 18:45:59 +0100
- To: "GEO" <public-i18n-geo@w3.org>
Folks, One of Karl Dubost's comments on the techniques plunged us into confusion during today's meeting. Here is what I took away wrt the problem statement and potential solution. Comments? The basic Problem: ================== How do we reconcile (1) Notes documents containing techniques descriptions that are frozen in time with (2) the need to represent constantly changing information about UA applicability of techniques? Background ========== I will refer to the short summary of a technique here as a 'recommendation'. The long version with explanations and examples is the 'detail'. We are producing the detailed techniques info as multiple W3C Notes, that will be individually frozen at certain, not necessarily the same, dates. We may, however, create new editor's drafts pretty soon after a Note is released, where we can add, modify, or remove specific techniques. These editor's WD's will eventually turn into new versions of a particular Note, obsoleting the previous version. On the other hand, we don't want to have lots of different outline documents tied to specific Note releases (as was the case previously when we generated the outline from a single document). The idea is to have a single, evergreen outline document at a fixed URI that lists the short summary of all techniques and points to whatever is the appropriate place to find the detail. We'd also like to ensure that as new versions of user agents become available, that we can update the information about their applicability to techniques. Previously all such information was derived from the same location as the technique detail and displayed in the detailed descriptions. However, once a Note has been published as such, we cannot change it. It would be easy to manage UA applicability information if the information about UA support were at a separate URI, but we feel it is important to have this information available on the same page as the technique recommendation. Way forward =========== As I see it: When we release a Note, it is a self-contained unit that, if it includes information about UA support (see below), does so according to our best knowledge at the date of the release of the Note. There is one outline document for all techniques. This outline doc is a view that is created by hand, so it is relatively flexible. We can point to detail for a given recommendation either in a published version of a Note, or, alternatively, in a new editor's draft. We can do that on a recommendation by recommendation basis. We should also work on the mechanism for extracting information about UA support so that it doesn't necessarily extract the informaiton from the place where we point to for detail (which is currently the case). For example: Suppose we release a techniques Note about language use that includes a section on use of the :lang selector and containing no information about language-related meta elements. Then we begin a new editor's draft of the Note, where we add information about (not) using language-related meta tags. Assume also that IE suddenly begins supporting the :lang selector. The outline document may point to the released Note for information about use of the :lang selector, but point to the editor's draft for new recommendations relating to use of the language-related meta element. Probably all information about UA applicability should be pulled from the editor's draft where it is kept up to date - ie. we may pull it from a different place than we point to for the detail. There should be a health warning in the released Note about the freshness of the UA applicability information in it, or (and I'm leaning this way) we should omit that information in the published Note (presenting it only in the outline view). One thing this would mean is that if we publish a new version of a Note, we should change all the links to detail in the outline so that they refer to the new document rather than the previous version. Unless I get comments to the contrary, I'll proceed down this path. RI ============ Richard Ishida W3C contact info: http://www.w3.org/People/Ishida/ W3C Internationalization: http://www.w3.org/International/
Received on Wednesday, 7 April 2004 13:46:04 UTC