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