[02:32] yod, agenda? [02:33] http://esw.w3.org/topic/QaDev [02:33] mostly type registry related [02:33] for markup val [02:36] * niq no further progress since last week on catalogue stuff [02:38] it appears that the types registry is one of the last things that need some work in the 0.6 -> 0.7 migration [02:39] namely, most of the important/real items in http://www.w3.org/Bugs/Public/show_bug.cgi?id=856 are related to it [02:39] one way or another [02:46] last week niq offered profiles for his cataloguemanager [02:48] TODO: update it for as-I-propose, generate the output, and put it all somewhere on view [02:48] could you detail how it would be used by the validator? [02:48] It's just an effort at modularising the task of maintaining the entity catalogue [02:49] i.e. all we have to maintain is one declarative file [02:49] what about local installations, would they need cataloguemanager? [02:49] Either that or a readymade catalogue [02:50] would it allow for subcatalogues? [02:50] readymade++ [02:50] e.g recs, wds, others [02:50] that we may want to separate (and not distribute all) [02:50] yes, if you want it to [02:51] that's one of the open questions, IIRC [02:51] we also have http://www.w3.org/Bugs/Public/show_bug.cgi?id=297 [02:51] scop: indeed [02:52] (just pointing it out as an example where (possibly) neither cataloguemanager or a readymade catalog would be satisfactory) [02:54] * niq invites folks to bug me until I reply to your last comment on that [02:54] the "we ship modified ones" bit has mostly been cleared, IIRC [02:55] ie. it was just some CVS keywords and such [02:55] Conclusion? Remaining issues? [02:56] I think the first thing to decide is http://lists.w3.org/Archives/Public/public-qa-dev/2004Oct/0024.html, then go into implementation details [02:57] historically, it appears we've been following new drafts before REC [02:57] Oh, right. Naming policy was to more or less replicate TR-space, extended to WDs etc. [02:58] hmmmm. [02:59] Yeah, we've tracked WD/PR/etc. more or less until they become REC; and then ditched the older versions (except not always nuked them from CVS). [02:59] as a result though, we sometimes kept old revisions of RECs, too, instead of overwriting them [02:59] We could ship more than one entity catalogue. A working one, and a historic-record one [02:59] Another divergence is MathML; where the kindly Math WG kept updating the DTDs _after_ REC. [02:59] right, that was MathML [03:00] yeah. That's why I wrote the CatalogueManager thing in the first place [03:00] I have no strong opinions against the way it has been, with the exception that more aggressive cleaning up (of WDs, PRs etc; not necessarily old RECs) would be welcome [03:01] it catches and updates it when they do that without telling us [03:01] My understanding is that W3C currently considers this a best practise and I would expect to see changing schemas, etc. more often now... [03:02] Would it make sense to say we only track pre-REC DTDs in pre-releases; opting instead to make point-releases if anyone moves to REC outside sane WMVS release milestones? [03:02] bjoern_: *Please* tell me you're kidding!? [03:02] seconded [03:02] well, a number of groups explicitly take schemas, etc out of the TR space so they can change the schemas without re-publication. [03:03] uh [03:03] * niq senses a greater need than he realised for CatalogueManager :-) [03:03] Microsoft Web©: The *new* W3C! [03:03] hehe [03:04] if the schema is not the normative version and the latter is updated as a fix, I guess it can make sense [03:04] s/the latter/it/ [03:04] If it's not normative WTF good is it? [03:05] if the spec prose is normative and the schema is a binding to a specific (schema) language? [03:05] what about not tracking any particular RECs at all in the validator proper; make sgml-lib a even more loosely coupled separate "project" instead? [03:06] scop: /me happy with that [03:06] scop: That might work. [03:08] publishing a nicely organized/catalogued collection of DTDs more prominently somewhere would be also beneficial for other apps besides the validator [03:16] The sgml-lib might benefit from decoupling from the Validator. Probably not for 0.7.0 though? [03:18] xover, I guess so [03:19] unless it proves small enough a task that it fixes our issues for 0.7.0 with the least amount of work [03:19] which I doubt [03:19] Ok. So what's next on the agenda? [03:20] The last paragraph of http://lists.w3.org/Archives/Public/public-qa-dev/2004Oct/0023.html still holds, should I commit? [03:20] YEs. [03:21] note that smil20 is currently a PER [03:21] http://www.w3.org/TR/2004/PER-SMIL2-20041105/ [03:21] Proposed edited recommendation [03:22] * JibberJim didn't know you could have them, why isn't CSS 2 one of those rather than a proposed errata which seems even more rotten ? [03:22] the next step would be REC so we'd have to update the smil20 dtd soon... [03:23] well, it isn't that much work. it could result in some CVS "pollution" though assuming we follow the past naming of dirs [03:23] I'm not sure SMIL2 validation ever actually worked. [03:23] I doubt anyone cared so far... [03:24] I am fairly sure it's been broken for a very long time at least [03:24] I assume they'll update the datestamp on next REC; meaning we add the new and cvs rm the old; the FPI will probably be the same, non? [03:24] fpi, yes [03:25] that's how I'd imagine it to go [03:25] "cool fpis do change ..." [03:25] Ok, so scop can just check in what he has and we'll deal with it once it becomes an issue. [03:26] ok. AI taken [03:28] do we have a policy now? [03:29] Maybe start a wiki entry to document this? [03:29] bjoern_, "only RECs for releases" was proposed and did not receive any challenge [03:29] (I challenged it sorta, by proposing decoupling...) [03:30] After decoupling, new REC == new release. Problem solved. [03:30] so recs only for now, until we decouple [03:30] * bjoern_ notes he does not really care much at this point... [03:30] exactly [03:31] bjoern_, why? [03:31] Number of new DTDs published as a REC approaching zero, perhaps? [03:32] yes, and schema management is far ahead... [03:33] http://www.w3.org/Bugs/Public/show_bug.cgi?id=82 [03:34] want to discuss whether we want to have install guides for every platform that we can include in our distribution [03:34] or happy with a generic guide and links to potential specific guides [03:34] see comments #2 and #3 [03:34] that's a distro-thing, innit? [03:35] not only [03:35] I think we should generally try to push pre-packaged versions instead. who has OS X (I might soonish)? any connections to http://fink.sf.net/? [03:35] question is broader, whether we want to "own" install instructions for each platform [03:35] Our turnaround is by definition faster than third parties. ADC doc won't cut it. [03:36] disagree on that [03:36] ADC is not too fast, but neither are we [03:36] on the other hand, current lack of install tuts suggest that we don't cut it either. [03:36] prepackaged ++ [03:36] We may not be able to provide docs for a given platform, but claiming the ADC doc as our documentation isn't good enough. [03:37] well, it is not our documentation, but it is sufficient imo [03:38] we could ask ADC if we can keep a local copy of their doc, and be able to update it ourselves [03:38] It was incorrect when it was published, and it will be again the second we release 0.7.0. [03:38] also note that installing the validator is actually quite simple if you manage to install apache, perl, opensp, modules, ... [03:38] of course, we won't hinder anyone to contribute better documentation to the validator [03:39] right, but most of those come with various OS's. [03:39] BTW, scop, yod and I have Mac OS X. [03:39] it will be wrong: yes. if we have our "local" guide, does it mean we will not coordinate with them to fix theirs, I don't think so [03:41] have never installed the validator on either of my OSX machines, though, always on linux boxes [03:42] regardless of what machine I am using, anyway, my take is that I'd rather maintain a good generic guide than botch many specific ones [03:43] ++ [03:43] but I may be too much of a multiplatform geek [03:44] install deps, copy validator, set paths in validator config, configure web server, done. [03:44] good general != botched specifics [03:44] xover, yes [03:45] but with a limited time, the correlation becomes higher [03:46] botched specific == no specific guide. correlation == 0. [03:48] my proposal: contact Nick Talbott && David Souza, ask if we can snatch their work as a basis for our local copy [03:49] as in we mirror their work or as in we will produce and maintain our own guide based on their work? [03:50] simply because I'm not willing to write one from scratch when there are good ones around [03:50] I think externally maintained guides are good enough and we should not make such duplicate efforts. [03:51] not my favorite option, I'd much rather just link to their work, but if we want local guides, I'd much rather we based them on existing ones [03:51] That why we haven't seen an english translation of the german install guide for windows? [03:52] I don't know why this has not been translated yet [03:52] in fact, I don't know whether it has been translated or not [03:52] If only we had an english speaking german with WIndows experience on the team… [03:53] I do not plan to do anything like that fwiw [03:57] well [03:58] as the-one-who-generally-writes-doc, I know I won't have much time for specific guides any time soon anyway, so I suggest we agree to disagree for the moment and go with the statu quo [03:58] Until we have a specific guide for a platform, we do our best to provide links to any third-party guides. Creating specific guides will not be a priority. … [03:59] The genric guide should be as good as we can make it; but our main strategy is to provide "installers" rather than encouraae manual installations. [03:59] That sum it up? [03:59] yes [03:59] I'm happy with it [03:59] 0.7.0 release announcement should encoure more guides, translations, etc [04:00] speaking of which... [04:00] as you may (or may not) have seen, i've put the error messages and explanations in localizable land [04:01] * xover had noted it, but not processed it yet… [04:01] which should be a good thing TM unless the list of errors changes [04:01] I was wondering, what's the odds of that? [04:01] very low, I hope [04:01] From upstream? Pretty much zero at this point. [04:02] great [04:02] Internally? 100% [04:02] and after we release 0.7.0? [04:02] because people will want to translate them [04:02] and if we have to re-organize the list of errors in n languages, it's going to be a massive headache [04:03] Ditto. But not necessarily in ways that would hamper l10n (possibly, but not necessarily). [04:03] regarding localization, how about a s/en_US/en-us/ to ease (?) conneg by matching what the browsers send? [04:03] IOS language tags. The current useage was more or less randomly chosen. [04:03] the browser might actually send en [04:03] I should note that with additional reporters (new error checks, etc) we might need to reconsider some of these things... [04:05] browsers send wildly different things, right, so I don't know how much unnecessary mapping it would reduce. probably some though. [04:05] HTTP RFC sez ISO language tag though, right? [04:06] right, IIRC [04:06] bjoern_, I think that's what xover was meaning when saying there is a 100% chance this will be re-organized [04:06] So that's our baseline; anything else is… uncertain. [people having to leave soon] [04:08] Leave current discussions in limbo and resume next meet? [04:08] we have a mail thread too [04:08] * xover is insanely behind on email but will try to keep up… [04:09] sorry for the rush, but yes, let's close this discussion at this point, fu2 later either by e-mail or next meet [04:10] ok. last "official" TODO item for link checker: http://www.w3.org/Bugs/Public/show_bug.cgi?id=896#c3 [04:10] anyone has anything else for 4.1? [04:11] * bjoern_ does not [04:11] I think we should move forward with 4.1 [04:11] ... anything else for 4.1 that is [04:10] agree with comment #4, FWIW [04:12] I'm hoping we can think of an alternative to cgi (i.e a queue) [04:12] but that's *not* for now [04:12] getting rid of http++ [04:13] what do you think, scop? [04:13] I think just a tiny doc update along comment #3 in #896, and push 4.1 to CPAN. [04:13] scop++ [04:13] sounds good [04:14] need separate announcement? [04:14] separate from? [04:14] ...just upload and update v.w.o? [04:15] It should have an announcement, yes. [04:15] yes [04:15] If nothing else it shows something is happening. [04:15] does not need to be pompous, but ann++ [04:16] I'll generate a changelog and add NEWS to CVS, yod takes over from there? Next meeting tentative 21 dec.