[21 Dec 04 18:01] qadev: http://esw.w3.org/topic/QaDev [21 Dec 04 18:02] I was wishing to get an idea of everyone's schedule in the next few weeks, know how much progress have been done if any while I was pretty much AWOL, discuss the feedback form I've started working on, etc [21 Dec 04 18:03] Hmm. Schedule... I'm off to the in-laws for Christmas; probably until after New Years, or until just before. [21 Dec 04 18:04] After that it's pretty much the normal insanity work-wise. [21 Dec 04 18:04] I /might/ find I have more available time while at the in-laws tho; if the GSM connection holds up. [21 Dec 04 18:05] k. [21 Dec 04 18:05] ** *bjoern_ has lots of exams in feb / mar...* [21 Dec 04 18:05] for my part, this is the holiday season, except that I've already taken my vacation. Which means I am likely to have time AND be left in peace [21 Dec 04 18:05] until mid-jan, probably [21 Dec 04 18:06] heh heh. We have stellar timing as usual. [21 Dec 04 18:07] okay, well, we'll do as usual. :) [21 Dec 04 18:07] Well, if I manage to bring myself more up to speed on the code during christmas, it may be easier for me to snatch an hour here and there for hacking on the validator in the new year. [21 Dec 04 18:08] xover, that would be nice [21 Dec 04 18:08] ** *xover is pulling down the FC3 ISO and installing VMWare on his laptop...* [21 Dec 04 18:08] I feel that the remaining bugs blocking 0.6.7 are parts of the code most of us aren't too familiar with [21 Dec 04 18:08] and I know at least Ville and muself are a bit shy to take it on [21 Dec 04 18:08] 0.7.0? [21 Dec 04 18:09] right... [21 Dec 04 18:09] thoughts on http://esw.w3.org/topic/MarkupValidator/M12N would be valuable... [21 Dec 04 18:09] Do we even have any bugs against 0.6.7 that might be worth fixing? [21 Dec 04 18:10] nothing urgent AFAIK [21 Dec 04 18:10] ... resist ... pointing ... meta bug ... [21 Dec 04 18:10] I was just reading that and have a few comments (better done in email). Very very nice work! [21 Dec 04 18:10] bjoern_, these are mostly post-merge bugs, aren't they? [21 Dec 04 18:11] I agree that there should not be urgent bugs. [21 Dec 04 18:12] bjoern_, very nice work. I'll put on my todo list to give it a couple hours [21 Dec 04 18:12] But I was more thinking in terms of features that might get rid of the meta-bug while keeping everyone happy (maybe). [21 Dec 04 18:12] (it's very much incomplete, I've just collected some random thoughts, it's merely to get a general idea...) [21 Dec 04 18:13] http://qa-dev.w3.org/wmvs/HEAD/check?uri=http://msdn.microsoft.com suggests that yod's verbosemsg fixes indeed restored the functionality [21 Dec 04 18:15] I've been getting more familiar with template structure and code around it, will reuse a lot of it for the feedback thingy [21 Dec 04 18:15] care to discuss that a bit? I need some input, and have a couple questions [21 Dec 04 18:15] Note that the templates could do with another restructuring before we release them. [21 Dec 04 18:16] (since we want to keep them a little more static for the translators after first release) [21 Dec 04 18:16] perhaps, yes [21 Dec 04 18:17] my experience with translators is that they are very tolerant wrt mixed code/text [21 Dec 04 18:17] but maybe *we* want to separate more [21 Dec 04 18:18] xover, if you have plans of how to cleanup the templates, I could certainly give it a go [21 Dec 04 18:18] Exactly, and it would be preferable to do that before any translators invest a lot of time on the existing structure. [21 Dec 04 18:18] Nothing specific; I just note that they're sub-optimal as they stand. [21 Dec 04 18:19] (and Ville likely agrees; he ditched the plan to use HTML::Template for CVSWeb after he had a look at my templates ;D) [21 Dec 04 18:19] :)) [21 Dec 04 18:20] HTML::Template is actually quite nice, I was positively surprised [21 Dec 04 18:21] Hmm. Speaking of... I'm not entirely sure I like keeping the verbosemsgs with the templates. And that ties in with Bjoern's M12N page, which will probably need to adress i18n. [21 Dec 04 18:22] ah? what's bothering you about it? [21 Dec 04 18:22] they're not templates, indeed, but it seemed rather natural at the time [21 Dec 04 18:22] hmm, I was going to note some issues there, e.g. whether we expect module authors to deal with translations or if that's validator business... [21 Dec 04 18:23] as a module author, I would like to avoid packaging and updating my modules with lots of translations in languages I do not read... [21 Dec 04 18:24] The vmsgs are sorta input/meta data, but the templates are more an aide to one particular output format / serialization. It's mixing logical levels. [21 Dec 04 18:24] bjoern_, ideally as I see it, the modules should generally only bother about logic and API, not much about the user interface (including languages) but I may be naive [21 Dec 04 18:24] I haven't really considered it in very much detail. It just struck me as "wrong" when I saw the committ message. [21 Dec 04 18:25] ideally the modules would not bother about natural language, but they need to include text in one language in order to be useful [21 Dec 04 18:25] (or easily usable) [21 Dec 04 18:25] My plan has long been that we will hide the OpenSP messages entirely from the user, in favour of custom ones kept in the vmsgs. [21 Dec 04 18:26] agreed [21 Dec 04 18:26] That would make the model more that the module provides one unique ID, and all text is looked up based on that. [21 Dec 04 18:26] xover, I see your point. I agree that it did not feel like "the right place" but I did not feel brave enough to shuffle directory structure to make it right [21 Dec 04 18:26] yup, we do in fact have that with OpenSP's message codes [21 Dec 04 18:27] Right. SO that we show OpenSP messages to the user today can be considered historical baggage. [21 Dec 04 18:27] my new appc sax module has more readable IDs such as element-lacks-xml-lang-attr [21 Dec 04 18:28] isn't it essentially done with having all messages (basic and explanations) in verbosemsg ? [21 Dec 04 18:28] One of my comments on M12N was that the IDs should probably be either URNs or OIDs (or OID URNs). [21 Dec 04 18:28] yod: No, the messages have format strings we'd need to process. [21 Dec 04 18:28] yes, I thought about using urns too... [21 Dec 04 18:29] I thought about a urn:cpan: namespace... [21 Dec 04 18:29] I'm sure we could get a branch of OID space from ISO. [21 Dec 04 18:29] Or from the IETF subtree if we were so inclined. [21 Dec 04 18:30] a urn:cpan namespace would have the benefit that it would be usable for other stuff... [21 Dec 04 18:31] especially as cpan already has namespace management... [21 Dec 04 18:31] (but lets not get lost in details at this point) [21 Dec 04 18:31] urn:cpan makes sense for identifying a particular module (which implements an observator or multiple observators). It seems mismatched for specific message ("observation"). [21 Dec 04 18:31] (right) [21 Dec 04 18:33] http://www.alvestrand.no/objectid/index.html [21 Dec 04 18:36] I think I even saw a more-or-less-finished mapping of this into URN format. [21 Dec 04 18:37] But it was just a random thought. I dunno how it stacks up against something like the urn:cpan thing; so we'll probably want to discuss this further at some point. [21 Dec 04 18:38] sure, let's keep the idea in a corner, it does look like something we want to look into at least [21 Dec 04 18:38] bjoern_: I'd like to see more on how you see the urn:cpan idea work, and how it maps to the rest of the stuff on the M12N page. [21 Dec 04 18:39] Maybe add a short description of the scheme on the Wiki? [21 Dec 04 18:39] going back to where this discussion started, I guess it might be a good idea to think further about how we organize our data, and I suppose this is tied to how we want to proceed with M12N [21 Dec 04 18:40] ** *xover also thinks Björn's work on the /M12N page and the experience from S::P::OpenSP is key...* [21 Dec 04 18:40] xover, yes, at some point... feel free to add some thoughts and pointers in a new section [21 Dec 04 18:41] ** *xover will do...* [21 Dec 04 18:41] Hmm. Ok. Should we jump back to the feedback page? [21 Dec 04 18:42] fine with me [21 Dec 04 18:42] hmm, yes, I guess we were pretty much done with templates, too [21 Dec 04 18:44] re- feedback page, Lachlan's message finally motivated me to do something about having a script for that instead of mailto: links and a static feedback page [21 Dec 04 18:44] I am thinking of: [21 Dec 04 18:44] - form based [21 Dec 04 18:44] - sends to w-v (but moderated) [21 Dec 04 18:45] - form is pre-filled with error message number and URI of validated document if GET from validation results page [21 Dec 04 18:45] - form has links to mail search on particular error message if applicable, link to general mail search otherwise [21 Dec 04 18:46] one thing I was actually wondering was whether to make this localizable or not. localizable is good (TM) but that may bring us feedback messages in "DAMN FOREIGNER" languages into w-v [21 Dec 04 18:47] Hmmm. msg number and URI should be always present (not visible, and deletable, in free-text field). [21 Dec 04 18:47] the css validator is mostly localized and the only problem so far was that people send questions in german, french, etc to the list [21 Dec 04 18:48] And having the form do the job means we no longer get a replyable email address. [21 Dec 04 18:48] oh, yes, and sender's address [21 Dec 04 18:49] although as you note, the sender may put some garbage in there, but then that's their problem, if they do not want a reply [21 Dec 04 18:49] the form could send mails from joe luser (by way of form system) [21 Dec 04 18:50] People may have trouble understanding the concept of a feedback form sending email to a public list, that is more obvious when they have to send an email from their MUA of choice. [21 Dec 04 18:50] IOW, they may go apeshit that we expose their email to spammers. [21 Dec 04 18:50] [[ [21 Dec 04 18:50] In order to make it easier to interpret the Markup Validator's error messages and help you fix your Web documents, we provide you with this feedback / help form. Messages sent through this form will be sent to W3C's publicly archived mailing-list www-validator ]] [21 Dec 04 18:50] ** Unknown command: MW [21 Dec 04 18:50] ** *bjoern_ wonders about the interoperability of mailto:?body=... compared to mailto:?subject=...* [21 Dec 04 18:51] IIRC the RFC advices against allowing ?body= for security reasons. [21 Dec 04 18:51] bjoern: works reasonably fine AFAICT, I'm using it on one of my sites [21 Dec 04 18:52] bjoern_, you're tempted to just fluff up the mailto: links? [21 Dec 04 18:52] that would make *very* large validation results pages [21 Dec 04 18:53] And run us up against max URL length in various MUAs and browsers (not to mention norton internet security and its ilk). [21 Dec 04 18:54] and that does not really let us explain what the feedback is really about. [21 Dec 04 18:54] well, I was thinking about offering a better mailto: link from the new feedback page rather than doing POST + server-side smtp... [21 Dec 04 18:54] ah, yes [21 Dec 04 18:55] one possibility... the feedback page generates a boilerplate email [21 Dec 04 18:55] and the user can copy paste into mailer? [21 Dec 04 18:55] or that, yes [21 Dec 04 18:55] Sounds like it would be quite confusing for many users. [21 Dec 04 18:55] true [21 Dec 04 18:56] hmm, my network went berzerk for a moment... [21 Dec 04 18:56] How about we just do the form as yod originally thought, just making note of the problems so we're aware of them, and then see how it works out? [21 Dec 04 18:56] and remove the mailto: links in the results page? [21 Dec 04 18:56] in favour of such links? [21 Dec 04 18:56] We don't have to be perfect, just better than we are today. [21 Dec 04 18:57] bjoern_, yes [21 Dec 04 18:57] Yes. Maybe provide the equivalent mailto: link on the feedback page for those that prefer them. [21 Dec 04 18:57] I am yet to figure out a good way to moderate these, BTW [21 Dec 04 18:57] ** *bjoern_ supports everything that yields in removing the mailto: links ...* [21 Dec 04 18:58] Lets put it this way; I'd been hoping the mailto: links would have been used by, say, Jukka and David and you lot, etc. [21 Dec 04 18:59] Not the "Free Tech Support" crowd as seems the rule now. [21 Dec 04 18:59] well, in all fairness we received a "real" suggestion for an explanation even today [21 Dec 04 18:59] well, yesterday [21 Dec 04 18:59] well, as I said when we discussed this last time, it worked for :8001 but only for that. [21 Dec 04 19:00] ** *yod thinks it gave us a good peek at how much users are at loss to understand the messages* [21 Dec 04 19:00] I was rather thinking about maintaining the messages in a wiki like fashion with some review before using them in production. [21 Dec 04 19:01] Maybe schedule a new discussion on the error message feedback (whichever method is used) prior to the 0.7.0 release? e.g. whether they serve any purpose, whether it's worth it, etc. [21 Dec 04 19:01] I don't regret the experiment, in any case [21 Dec 04 19:01] xover, fine with me [21 Dec 04 19:04] Ok, what's next? [21 Dec 04 19:05] port restriction policy? [21 Dec 04 19:05] did we finish the dtd / catalog discussion? [ yod drops, network outage - bjoern takes on chairing ] [21 Dec 04 19:06] If there're any open issues on the catalog/dtd stuff, I think 1) we should have Nick here and/or 2) I'm not really up to discussing that right now. [21 Dec 04 19:07] ** *bjoern_ agrees with #2 :-)* [21 Dec 04 19:07] So... Port restrictions... [21 Dec 04 19:08] My take is pretty much summed up in my email to qa-dev. [21 Dec 04 19:10] maybe someone should grep the logs to see whether people attempt to "validate" host:something-but-80? [21 Dec 04 19:11] there are some good reasons to block ports and there are good reasons not to do that, neither of which seem very relevant... [21 Dec 04 19:11] Is that really relevant? [21 Dec 04 19:11] what exactly? [21 Dec 04 19:11] (the log grepping) [21 Dec 04 19:13] AIUI there is extra code in CSSVal to block more-or-less arbitrary ports, and no specific reasons why it's done. [21 Dec 04 19:14] it reduces the possibility of abuse of the service... [21 Dec 04 19:14] To me that reads pretty clearly that we should just get rid of the restriction; at least until we make an informed decision and implement it universally across our toolset. [21 Dec 04 19:14] (and no, it's probably not that relevant, I was just thinking about getting some hard data...) [21 Dec 04 19:15] Grepping tells you how many people try to use other ports; but that's analogous to browser stats, it doesn't tell you how many don't try it because they know it doesn't work. [21 Dec 04 19:16] I was thinking about the markup validator's logs as it works for the markup validator... [21 Dec 04 19:16] I agree that we should have a universal policy [21 Dec 04 19:16] Oh, like that. Sorry... [21 Dec 04 19:19] Ok, put another way... Do you have an opinion that leans clearly either way on this? [21 Dec 04 19:20] no (as i've said on the mailing list...) [21 Dec 04 19:21] I've reported the original bug in part because it affected me, [21 Dec 04 19:21] My impression from the list was that everyone is considering blocking only because it was already implemented; if it hadn't been there it probably wouldn't even have come up. [21 Dec 04 19:21] I've been running netcat on my firewall to easily sniff the css val HTTP request on a blocked port, for example [21 Dec 04 19:22] probably, yes [21 Dec 04 19:23] Ok, then we probably won't get any further without checking whether yod has any strong opinion on it. [21 Dec 04 19:23] yup... [21 Dec 04 19:26] ADJOURNED. [21 Dec 04 19:26] next meeting, see the wiki [21 Dec 04 19:26] once someone updates it. [21 Dec 04 19:28] ** *bjoern_ sends logs to yod*