- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 20 Jun 2011 07:23:51 +0200
- To: Chris Weber <chris@lookout.net>
- CC: "PUBLIC-IRI@W3.ORG" <PUBLIC-IRI@w3.org>
On 2011-06-20 00:18, Chris Weber wrote: > On 6/19/2011 10:33 AM, Julian Reschke wrote: >> On 2011-06-18 19:15, Chris Weber wrote: >>> On 6/18/2011 4:56 AM, Julian Reschke wrote: >> >> That looks like a cool approach for testing host name parsing and >> resolution! > > I scrapped the GUID idea, which worked well but only gave me the benefit > of being able to correlate a given test Id with the specific Web browser > that initiated the DNS request (e.g. there's nothing in a DNS request > which I could otherwise use to identify the browser). > > I expect most browsers are using the platform OS to resolve DNS so I'm > okay with this for now. Of course there's always apps like Skype which I > believe uses it's own DNS libraries... > >>> Otherwise, what are your thoughts on including an easily identifiable >>> token that could be placed anywhere in the test string? >> >> Good question. >> >> For generic parsing tests, there really isn't a single component on >> which presence we can rely on. For instance, we may have relative >> references (no authority), empty paths, missing queries, or missing >> fragment identifiers. > > I understand and am still wondering if a generic Id format could be used > in the other parts that are not missing. > >> For now my plan is to group the tests into groups (like "RFC3986", >> "RFC2397"...), and build a test id by numbering within the groups; then, >> for the more "interesting" tests we can assign a unique identifier >> within that group. >> >> Best regards, Julian > > I like the grouping idea. Right now I'm pulling as much as I can from > Adam's Webkit test suite, into the XML format mentioned earlier. I'm > still including the test Id as part of the hostname (e.g. > http://0013.iris.test.ing). If you wanted to be super generic across all > groups could you have a test Id format that was unique enough (e.g. 6 > digits) that it could easily be found with a regex, and was usable in > cases where any given component was missing? Where 000013 is the test id > below: > > http://000013.iris.test.ing > http:000013 > http\\000013 > 000013:foo/bar > mailto:000013@example.com > mailto:chris@000013.iris.test.ing > urn:ietf:rfc:000013 > opaquelocktoken:000013e0-1bb3-11df-9f3e-a5b17f9068f4 > data:,A%20000013%20note%25foo#bar > > In each of these cases I should be able to identify the test id within > the string. Also a good idea. Unfortunately then we can't simple use test cases verbatim, and need to modifiy them before inclusion. Hmmm.
Received on Monday, 20 June 2011 05:24:23 UTC