- From: Dimitris Dimitriadis <dimitris@ontologicon.com>
- Date: Tue, 28 May 2002 23:23:16 +0200
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: David Marston/Cambridge/IBM <david_marston@us.ibm.com>, www-qa@w3.org
On Tuesday, May 28, 2002, at 05:00 PM, Alex Rousskov wrote: > On Mon, 27 May 2002, Dimitris Dimitriadis wrote: > >> On Monday, May 27, 2002, at 06:56 PM, Alex Rousskov wrote: >> >>> From technical point of view, "pointing to normative sentence in a >>> Recommendation" does not imply a need for structure or W3C >>> documentation standard. An external document can point to normative >>> sentences using a variety of already available techniques, which will >>> depend on the format of the Recommendation and on the test tool >>> preferences. >> >> [dd] You're right, it doesn't necessarily imply that. However, >> given the possible migration to a common markup for specifications >> being discussed here, it may seem to be a positive spinoff to have >> a uniform linking mechanism, especially considering that there are >> tendencies to try to streamline the test suites being produced. >> Pointing to a spec can of course be done in a variety of ways, but >> the question I raise is whether it is desirable to make the >> W3C-produced test related efforts do it in similar ways. > > I think it is desirable for W3C-produced documents to have addressable > text. Period. > [dd] That's a good starting point. > Everything else, including a complex uniform spec writing language > (XSpec++ or whatever) and a complex uniform linking standard > (XSpecQuery or whatever) might create problems for some working groups > and for some documents while offering marginal benefit to others. Each > WG should be free to select the language to write their specs in. QAWG > can encourage certain formats (e.g., xmlspec) but should not require > them because even plain text is addressable. > [dd] It might. But it also might not. It remains to be seen how much more benefits we get than drawbacks we suffer. Also, we shouldn't confuse the question of how difficult it is for existing Working Groups to migrate to a particular spec authoring scheme with the question of how difficult it is for a newly formed WG to adopt a particular spec authoring scheme. I suspect the latter is easier. So, at worst, we have a transitional phase of trying to convince existing WG to migrate before us, but it is not indefinite. > Let's not try to kill diversity just because some problems are easier > to solve in a homogeneous environment. N years from now, our claim > that XFooBarL is the absolutely best spec-writing/linking language > will seem funny and naive. > [dd] I don't think anyone wants to kill diversity. On the level of authoring, I think the trivial point is that we want to make it possible for WGs to produce specifications for technologies. If you will, we want to provide them with a (what we believe to be) a (motivated and rational) specification authoring scheme, something like a common alphabet. I myself have experienced that writing the contents of the specification is much harder than the markup one uses, and I think this would go for most Working Groups if they looked at it that way. > If we assume that XML for documents is like DNA for life forms, we > could stop at that level of homogeneity and let the time (WGs) shape > specific spec writing languages. Until DNA-less aliens show up. > [dd] Since I'm a great afficionado of metaphors, I think the W3C should not be to Working Groups what the UN is to nations insofar as language is concerned, but rather insofar as human rights and other principles are concerned. All countries are individual and helped to further their particular skills, but using uniform tools and procedures. However, I think most people would agree that things would be much easier if linguistic barriers were not there, something which one can argue for in the case of technology specifications without running the risk of being accused of having totalitarian views. > > On Mon, 27 May 2002, David Marston/Cambridge/IBM wrote: > >> We've already tried this with the first wave of XSLT/XPath tests >> being released through OASIS. See >> http://www.oasis-open.org/committees/xslt/index.shtml for the >> overview. In my opinion, and I'm the person who has done more work >> on these XPointer-style references than anyone, it is a lot harder >> than you suggest. > > I did not suggest that it is easy or difficult, just pointed out that > it is possible in some cases. > >> You want to be able to query the test suite in ways like: Find all >> the xsl:number tests where level="any" and count is defaulted. > > I would not use XPointer-style queries for this kind of task. > > > Moreover, I was under impression that the scope of this thread is > addressing specific pieces of specs rather than ability to "query the > test suite". The latter is a very different problem, IMO. In other > words, being able to extract known-in-advance specific pieces from the > spec is very different from being able to search the spec (suite?) for > unknown-in-advance information. > [dd] In the DOM TS, we made the experience that being able to query the suite occurs not only when you don't have known information up front. It was just a means for being able to do so, to begin with. Also, but this is a matter of discussion, I take the issue of being able to adress a spec to be one special case of being able to adress at all, something which we can do from tests too. Why not achieve uniformity, in case it simplifies and gives rise to added value? > Perhaps we should agree on the scope first! > > Alex. >
Received on Tuesday, 28 May 2002 17:23:23 UTC