Agenda at http://esw.w3.org/topic/QaDev ** Administrative -> lists, newsgroups, sites to attract more people? ** 01:07 context: I recently poked around to answer a relatively old question for NNTP servers 01:08 ... ended up making myself a setup for usenet for the first time in years, subscribed to comp.info.... groups 01:09 and I was wondering if there were other groups, lists, sites that you know where we could make a bit of publicity to get help on the validator 01:09 we have a list, not sure about newsgroups, but some kind of web forums could be attractive for not-old-farts-like-me-who-prefer-mail 01:09 w-v is not the best place, most people there already help as much as they can/want 01:10 No. Web. Boards. Of. Any. Kind. Period. !. 01:10 scop: you mean having a www-validator forum? 01:11 yeah, well, that's what I mean, but there's no way I'm personally promising to ever be present there :) 01:11 + yod was more thinking of existing lists, boards, places , not something to create 01:11 ah 01:11 join, participate a bit, represent the validator when needed and point to feedback.html when people rant 01:12 granted, that's a time investment, but I'm tempted to give it a try 01:13 Use public-evangelist to find blogs that ocasionally deal with vwo? Possibly resurrect the vwo/blog/? 01:13 laplink: yeah, that's not a bad idea, the public-evangelist is a different crowd than the one on w-v 01:14 I think I'll ask karl to start a thread on that list, he likes it :) 01:16 anyway... if you see people on a list or a forum discussing the validator, consider pointing them to either feedback or 01:16 + yod (finds pointer) 01:16 http://lists.w3.org/Archives/Public/www-validator/2005Apr/0031.html ** Administrative -> possibility of a f2f meeting this summer? ** 01:18 The QA WG will hold a meeting (possibly its last) in Dublin in August 01:19 I'm not sure yet if I'll go, but if I do, there's the idea to use the opportunity to actually come see you 01:19 e.g find a location somewhere in northern europe for us to meet 01:19 question is: are you interested by the idea? 01:19 It's not impossible that I'd be able to attend that. 01:19 ditto, I'm planning to be on vacation in August, but no firm plans yet 01:19 (regardless of logistics concerns, for the moment) 01:20 cool, that's pretty positive 01:21 I have no idea yet how we would do this, since we'd still be rather scattered in Europe, but if it's in the realm of possibles, I can investigate a bit further 01:22 sounds like it is. I see the meeting is scheduled for Aug 8-10 01:22 that's right 01:23 I'll ask the other "regulars" too, can also drop a line on w-v later if the probability of doing this is high ** Link Checker -> Status of Bug #1170 ** 01:25 yep, I added some comments in the wiki 01:25 scop, I saw your update to the wiki an hour ago 01:25 do you have a bit more details on the issues the fix would cause? 01:26 ok, first the layout: minor concern, but hard to get it nicely aligned with the other options in the form (and I don't want to use tables for that) 01:26 + yod thinks your alternate solution - ignore recursion number if box not selected - is acceptable, though 01:27 second, the usability: removing the checkbox would expose users to the "-1 means unrestricted" recursion 01:27 +1 for no tables, and I know styling forms can be a challenge 01:27 most users will just want to recurse or not, asking them to enter numbers is a bit much IMO 01:28 Define a range of valid and allowed recursion depths; anything not matching this pattern means unlimited (up to internal max limit)? 01:28 sure, but users would still have to enter numbers 01:28 Default to something sane? 01:28 I think 0 is the best default... 01:29 0 is no recursion, right? 01:29 right 01:30 well, except that currently, checkbox checked and 0 in depth means unlimited 01:30 but conceptually, I think "do not recurse" is a good default 01:30 ah, I thought I remembered that 01:31 alternatively, we could use a drop down 01:31 no recursion, 1,2,3, unlimited 01:31 that's not as flexible as a textbox, but I doubt users of the web interface need more than this 01:31 (?) 01:32 yeah, that'd work for me 01:32 users needing more power could just enter their preferred value in the URL :) 01:32 The count goes: 0, 1, all. 2 and 3 do not exist. 01:32 plus, with the 1s wait issue, I'm not even sure who can use recursive with the web interface 01:33 but that's another problem 01:33 I do recursive checks every now and then... 01:33 laplink++ in principle, perhaps add 5 between 1 and unlimited though 01:33 I mostly do single pages with web, for recursive I use the commandline 01:34 (/me sounds like a credit card ad) 01:34 (none) - 1 - 5 - (unlimited) ? 01:34 works for me 01:34 and as you said, power users will know how to hack it 01:34 Either it's a boolean -- i.e. a checkbox, no text field / dropdown -- or you can enter any number. Randomly chosen increments are bad. 01:35 s/bad/Bad[tm]/ 01:35 hmm 01:36 And overloading a numeric value to also hold boolean semantics is bad. I.e. valid value => that level of recursion; no value or invalid value => no recursion. 01:36 randomly chosen increments are limiting, but so would be just a checkbox 01:36 + laplink is trying for the Good Human Interface Design[tm] angle here... 01:37 yes... 01:37 dropping the depth option altogether could be one solution too 01:37 And in general, good UI requires you to make the hard choice instead of foisting a lot of descisions masquerading as "options/choice" on the yser. 01:38 Har internal limit of 3 or 5 (or whatever); and make recursion a boolean? 01:38 we already have a hard max # of documents 01:38 (150) 01:38 150 01:39 number of docs != max recursion depth 01:39 + laplink thinks boolean + internal limit would make sense to him... 01:40 + scop is not quite convinced why recursion depth needs to be limited 01:40 so you would remove the possibility to limited recursion? 01:40 Maybe it doesn't need to be? I dunno... 01:40 (I assume there's loop protection in place already) 01:41 yod, yes, that's an option IMO: basically just remove the depth text field, but leave URL param processing for compatibility and hackers 01:42 laplink, no loop protection per se, but dupe checking 01:42 (IIRC) 01:42 + yod looks at a few known recursive services, see that most of them are boolean 01:43 some stats from current vwo log: 01:43 2027 checklink invocations having depth= in the URL total 01:44 376 of them have a non-empty depth 01:45 oops 01:45 1330 total, 102 with non-empty depth is more close 01:46 sounds small enough 01:47 + yod is still a little concerned that we'd remove the relatively fast "1" recursion level 01:54 vast majority is 2 or 3, slightly less of 1, 4, 5, and a few others 01:57 So pick the median or average and stick to it? 01:57 or just "fix" the entered depth to be ignored if checkbox is not checked... 01:58 or do nothing at all 01:59 3 people discussing, and already 5+ alternatives :) 01:59 I think I'd rather keep the choice, and outputs a warning if checkbox is not checked and depth entered 01:59 (does that make it yet another alternative? ;) 02:00 is it necessary to warn about such a thing? the command line version doesn't either, but it documents -D implies -r 02:01 perhaps not 02:02 aaargh, can't be *this* hard 02:02 + yod chuckles 02:03 leave as is, and document the implied function in the title/tooltip? 02:04 or in the normal text 02:04 in the normal text 02:05 so like: "...depth: [ ] (implies recursion)" 02:05 this isn't a great solution, but at least it leaves the door opened for a later fix if we figure out something 02:05 Looking at the interface with my HI hat on, I'd say nuke everything except the first to checkboxes and move the submit button up to the text (URL) field. 02:06 kinda sorta agreed, but I'd like as minimal as possible changes for now 02:06 The last three switches are things that foist a decision on the user instead of picking the right default behaviour (which involves a tradeoff). 02:07 (this is a "review", not concrete suggestions for changes) 02:07 last three == no accept-language, recursion, and cookie stuff? 02:08 Yes. 02:09 A-L is technical mumbo-jumbo. Recursion should be a default. And the cookie stuff should be always remembered, or never. 02:10 OTOH, I might at some point in the future put my geek-fiend hat on and come back arguing for an "Advanced Options" page where that stuff is brought back. :-) 02:10 A-L comes from the user's browser, and cookies are what they are; I guess there have been privacy related reasons for those options 02:10 I was about to say that... 02:10 we're heading toward an advanced options alternate interface 02:10 not sure if it's worth it given the number of options 02:11 we could, indeed, review the interface and separate "normal" options from more advanced, perhaps with more text around them 02:11 there has also been discussion about _completely_ different WLC interfaces which is why I'd keep the changes now as minimal as possible for now 02:12 alright... let's just make the current behavior better documented on the interface for now 02:12 we can then review the whole interface more peacefully 02:12 phrasing suggestions welcome 02:13 "...depth: [ ] (implies recursion)" <--- sucks 02:14 how about 02:14 [] check documents recursively (automatic depth) 02:14 ... or choose a recursion depth [ ] 02:14 ? 02:15 not sure the (auto...) is even needed 02:15 if it's bad, you can say it :) 02:16 no, not bad, phone ringing... 02:17 but the relation is not "or", if both are set 02:18 not an xor :) 02:18 right 02:19 okay, that's good enough for me 02:19 I guess it does still allow to use both, but the interface suggests to use either 02:19 laplink, any opinion? 02:20 defer the issue or go all the way; no amount of patching the description will save the current UI. 02:23 yod, strong opinions against deferring? 02:23 no, it's not a big issue... I'm thinking that the best is the enemy of good, but if we keep this discussion in mind when eventually reviewing the UI as a whole, then it won't have been a waste of time 02:24 let's LATER and move on 02:24 so be it. deferred, and will push $TNV as it is now to CPAN today or tomorrow ** SGML-lib changes (custom DTDs etc) ** 02:26 http://dev.w3.org/cvsweb/validator/htdocs/sgml-lib/sgml.soc?rev=1.15&content-type=text/x-cvsweb-markup 02:27 I tested 1.14 as suggested (by Bjoern?) and indeed it worked better, with docs using custom DTDs at least 02:27 was wondering what the 1.14 - 1.15 patch was fixing 02:28 It adds the instrumented DTDs (sgml.dtd and xml.dtd) and I needed to nuke OVERRIDE NO to make them work in some cases (which details I can't recall ATM). 02:29 Possibly it's Bogus FPI + SysID; with OVERRIDE NO onsgmls will pick the SysID instead of dispatching based on the document type name. 02:30 => the bad FPI doesn't get detected if the SysID is correct. 02:30 (which is possibly an acceptable tradeoff) 02:31 maybe we could use another mechanism to check the consistency of FPI vs system with another mechanism somewhere down the road? 02:31 That particular problem may also be suitable for defering to when we land S:P:O. 02:32 indeed 02:32 It's not the consistency; it's catching bogus FPIs. 02:33 will emit no warning. *IIRC* 02:34 that's what I meant by consistency, bad choice of words, sorry 02:34 so it will be an issue for e.g bad copy-pastes of doctype or typos 02:35 yeah 02:36 no warning is too bad, but I am not comfortable with the (arguable) regression 02:36 I think we should look into other mechanisms to check for bad FPIs 02:37 do you think it's acceptable? 02:37 I have no opinion either way ATM; but I think it likely that reverting this change will turn out to be the necessary short-term path. 02:37 BTW, while looking at this issue: Generate test cases! 02:37 yes 02:38 ACTION yod to commit test cases for custom DTDs 02:38 And comment what they're testing, ideal behaviour, expected actual behaviour. etc. 02:39 right 02:39 will do, and will revert 02:40 (and BTW; revert by getting the diff and applying it in a new revison. don't go 'cvs admin'ing or fiddling with ,v files) 02:40 hmm, why no cvs admin? 02:41 (I see many people being uncomfortable with cvs admin, just curious as to why) 02:41 It rewrites history; which is anathema to revision control. 02:41 fair enough 02:41 I see your point 02:41 In this particular case, I want to preserve that history for when we may have to "revert" yet another time. 02:41 agreed 02:42 now, I "just" need to fix the bit of logic no FPI == no doctype 02:43 anyway, that's for another time [meeting formally adjourned at this point, more discussion on the topic followed] 02:43 No FPI = No DOCTYPE iff the FPI would have been a W3C one (as all W3C Recs require an FPI). 02:45 well, we could continue this discussion, or adjourn... I think scop has to go 02:47 laplink: true re- W3C recs, but this might be too strict a check if we want to have the validator opened to "more" validation 02:47 but it's an interesting question, whether it's a generic markup validator or should focus on doing the best of jobs on the RECS 02:48 It can do both; it's just difficult to implement the distinction. 02:49 yeah 02:49 and it's going to get more difficult since we are looking at future recs without as much as a dtd 02:50 Jukka's hobby horse might actually help here: don't say "valid foo", say "(no|# of) errors found" 02:51 A lot of our FPI dependance is in being able to say "HTML 4.01 Strict" etc.; without trying so hard for that we'd have a lot easier time doing the right thing with these issues. 02:51 good point 02:52 Our other big need for an FPI is in looking up extra constraints (MIME, root element, etc.); which 1) can be done by URI, and 2) are value-added features (not strictly validation). 02:52 I wonder what would be the reaction to such a change (not counting Jukka's and other regulars on w-v) 02:53 right, these could be done without any change to types.cfg as far as I can tell 02:54 Rigt. So there are ways we could go that would alleviate some of these headaches. 02:55 we can stop focussing so much on getting them displayed in our result pages; lack of a badge due to odd doctype issues is not the end of the world. 02:56 The "here's the badge you can use" code doesn't need to get all the edge cases correct.