15:55:47 RRSAgent has joined #htmlt 15:55:47 logging to http://www.w3.org/2012/11/20-htmlt-irc 16:04:34 Not sure if plh will attend.. 16:04:53 IMHO we can catch him up if he attends late 16:05:07 Sure 16:06:10 Here is the agenda I sent out to the list http://lists.w3.org/Archives/Public/public-html-testsuite/2012Nov/0003.html 16:06:56 Main item is discussing the test reorganization 16:07:49 Here is the thread on the list about this http://lists.w3.org/Archives/Public/public-html-testsuite/2012Oct/0027.html 16:10:12 James did you have any further thoughts? 16:10:52 Not really. I don't have time to work on it right now, but I think it is a net win, although there will be a little bit of tedious work to get it set up 16:12:15 I think the structure is a little too deep 16:12:35 I would prefer something like this... 16:13:04 E.g. http://www.w3.org/TR/html5/infrastructure.html#utf-8 would map to /infrastructure/utf-8/ 16:13:39 Or... 16:14:12 http://www.w3.org/TR/html5/dynamic-markup-insertion.html#document.write() woudl map to /dynamic-markup-insertion/document.write/ 16:14:30 I don't think splitting it like that makes any sense 16:14:41 There are two problems 16:15:08 s/woudl/would/ 16:15:17 One is that the spec splitter doesn't group things together in an entirely logical way so if you based things on the multipage version you would get weird grouping 16:15:57 The otherone is that the lack of heirachy is less flexible; if you have tests that cover the whole of drag and drop, for example, you might want to put them in a parent directory 16:16:19 Which you can't really do with your system. Or you can but you can't tell what's a parent of what 16:16:52 So using the single page spec how would http://dev.w3.org/html5/spec/single-page.html#document.write() translate? 16:17:50 Let me try... 16:18:55 bug in irc... 16:19:16 Z Elements Z Dynamic-markup-insertion Z document.write 16:19:23 Where Z == / 16:19:45 Sorry but IRC seems to eat the stream when I added / 16:19:48 ??? 16:20:19 make sense? 16:21:44 ..or did you think we all need to add Semantics, structure, and APIs of HTML documents to the path as well 16:22:40 Well I'm not sure. Whe I did this before i had semantics_structure_apis/elements/dynamic_markup_insertion/document_write 16:22:50 Or something 16:24:21 Ah...so you just truncated Semantics, structure, and APIs of HTML documents to semantics_structure_apis 16:24:53 Right 16:25:21 I recall that the #s don't really change 16:25:24 It was entirely human driven so I didn't have to have an algorithmic way to get from the section heading to the short name 16:25:38 The fragment ids can change 16:25:47 Ms2ger has joined #HTMLT 16:25:57 They aren't in the source, but added by anolis 16:26:05 Look it's Ms2ger to confirm this :) 16:26:54 ? 16:27:25 jgraham, say again? 16:27:33 Just that anpolis autogenerates fragment ids 16:27:37 Yep 16:27:39 *anolis 16:30:06 OK so how about this... 16:30:18 Semantics, structure, and APIs of HTML documents 16:31:03 Spaces would get turned into an '_' 16:32:23 FWIW I think just picking a shortname for each heading would be fine, and having a machine readable section anme:directory name map 16:32:29 ..and we would 'dump' chars that need to be encoded (e.g. ',' and ':') 16:32:44 No point in ending up with 300 character pathnames 16:32:55 Particualrly if people are trying to use Windows :) 16:33:30 (dunno how mercurial manages, but I have had problems with > 255 character pathnames on Windows before) 16:33:36 (with svn) 16:38:10 I think we should be fine... 16:38:27 Quickly looking at one of the deeper/longer paths 16:38:29 The elements of HTML - Embedded content - Requirements for providing text to act as an alternative for images -A phrase or paragraph with an alternative graphical representation: charts, diagrams, graphs, maps, illustrations 16:38:42 4.8.1.1.3 16:38:53 Only ends up to be 224 chars 16:39:17 Which only gives you 30 characters for your own path 16:39:57 (turns out I can't remember what Windws paths look like enough to give a good example, but that seems quite short) 16:41:04 c:\Documents and Settings\username\specifications\html\testsuite\ 16:41:05 I an application calls a legacy API MAXPATH == 255 chars 16:41:06 http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx 16:41:57 So in the example above would be fine 16:42:13 Especially if we dumped the ',' and ':'s 16:42:41 We could also dump the spaces 16:43:07 Well, I am injclien to leave the details to whoever does the actual work 16:43:11 *inclined 16:43:22 Dunno where that came from 16:43:39 Given their is 778 sections I don't expect a person to do this manually, but rather a script 16:44:04 Perhaps, but some manual work will be needed 16:44:32 Moving stuff into the new structure would take some time... 16:45:10 Though I'm not convinced it needs to be perfect - down to the leaf node 16:46:04 No, for sure 16:46:11 For example It would be fine to have parser tests under 'Parsing HTML documents' 16:46:17 Exactly 16:46:29 The main idea is that going forward we don't need to have so much explicit metadata 16:46:43 Since people typically don't write that 16:46:58 And as a result we don't really have any idea what our tests cover 16:47:54 I would also say that though a test could test multiple sections... 16:48:26 Yes, almost all do, although some moreso than others 16:48:47 In that case I thinkit is fine to pick a random section and if you want to do better add explicit metadata 16:48:56 Well "random" 16:49:07 One that seems appropriate 16:49:13 ...it would be placed in the location that the test is primarily testing 16:49:39 Yes. Or if you can't decide flip a coin 16:49:59 The idea is not to be perfect, it's to be \delta better than today 16:50:44 OK sounds like we agree 16:51:55 Now since we have the whole HTML5 and HTML.Next stuff going on I think we need to add a HTML5 to the path 16:52:31 Then we could create another folder for any extension spec (canvas2) etc.. 16:52:34 I think that could be the wrong solution to that problem 16:52:53 tmpsantos has joined #htmlt 16:53:19 It is possible that the right solution is branches 16:53:31 or we can have a text file for each spec that list the 'approved' tests for each spec, extension spec 16:53:39 in hg (or in git, where they make sense to me) 16:54:44 You maintain the commits that don't apply to HTML5.0 on a seperate branch that is frequently rebased 16:56:56 so then if someone is creating tests for canvas2 they check into the canvas2 branch 16:57:27 Then if/when this gets included into the HTML5 spec it gets merged into the HTML5 branch 16:57:39 Like wise... 16:57:59 We woudl have a submission branch and a approved branch for HTML5.0 16:58:01 Well that is one way that could work 16:58:19 Although I was thinking of a two-branch solution 16:58:41 Then when a test(s) are approved we just merge them from the submission branch into the approved HTML5.0 branch 17:00:47 Well, if we went the full github/pull request route that would be what we did 17:00:55 I am not adverse to that route 17:02:25 For people offline here is a pointer to some Hg branch stuff 17:02:26 http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ 17:02:36 http://mercurial.selenic.com/wiki/Branch 17:03:42 Now one issue that comes to mind is what would get prop'd to w3c-test.org? 17:03:49 Would we do this for each branch? 17:04:08 That is an interesting quesiton. Could have one for each branch 17:06:33 I suspect it would look like this.... 17:07:20 http://www.w3c-test.org/html/html5/LoadingWebPages/ 17:07:46 For the approved html5.0 tests 17:08:04 Then people woudl submit into another branch... 17:08:12 s/woudl/would/ 17:08:22 That would map to... 17:08:44 http://www.w3c-test.org/html/html5submit/LoadingWebPages/ 17:09:59 For an extension spec it would look like... 17:10:35 http://www.w3c-test.org/html/Canvas2/HitTesting/ for approved tests 17:10:56 and http://www.w3c-test.org/html/Canvas2submit/HitTesting/ for test submissions 17:12:52 With the html5.0 approved tests being the 'main' branch 17:14:06 We could certainly have multiple working copies on w3c-test.org corresponding to different branches 17:14:16 such that you could merge stuff from canvas2 into html5.0 (approved) 17:14:54 But you would not be able to merge stuff from the canvas2 into the html5.0 submit branch 17:15:23 Since canvas2 and html5.0 submit branch would be 'children' of the main branch 17:21:12 We would have named branches for each 17:21:13 http://mercurial.selenic.com/wiki/NamedBranches 17:24:35 Do you oppose this change/changes? 17:25:32 I think this is a reasonable general direction. I have not yet fully considered all the details 17:26:04 OK well take some time to think about this... 17:26:22 It's far beyond the meeting allocation time, though a good discussion 17:26:37 Good to see the drag and drop test submissions 17:26:55 Yeah, it is unfortunately a) large and b) lots of manual tests 17:27:10 I have not looked at them in depth... 17:27:20 I'm not sure how to avoif those problems; aiui all the bits that can be automated have been 17:27:33 Though here are some drag and drop tests that Microsoft submitted 17:27:34 http://www.w3c-test.org/html/tests/submission/Microsoft/dragdrop/ 17:27:48 Some are manual and when possible they are automated 17:30:36 Shall we adjourn? 17:30:41 Sure 17:31:00 RRSAgent, make logs public 18:30:28 Ms2ger has joined #HTMLT