Re: Conformance requirement markup and test metadata (take 2)

On 9/5/11 6:29 PM, "Linss, Peter" <peter.linss@hp.com> wrote:

> On Sep 5, 2011, at 3:56 PM, Alan Stearns wrote:
> 
>> On 9/5/11 3:22 PM, "Linss, Peter" <peter.linss@hp.com> wrote:
>>> 
>>> It's entirely feasible to allow the tests to simply link to other areas of
>>> the
>>> spec. The harness (and Shepherd) import tools will need to do a deeper
>>> search
>>> of the specs to find all these link points and determine which section
>>> they're
>>> in. Right now these tools only look at the spec's table of contents. So long
>>> as the link points are determinable via markup it's a manageable problem.
>> 
>> If you're OK with dual-purposing the specification links, then I'm happy
>> with using the existing format instead of inventing something new. Just to
>> be clear - the primary specification link could be any anchor in the spec,
>> and the tool would determine the enclosing section. Is that correct?
> 
> Any anchor in principle, yes. I'd rather not have to track every single ID in
> every spec, so I want to limit the link targets to a reasonable deterministic
> set.
> 
> I'm not sure exactly where your conversations with Elika wound up, I presume
> we're looking at section anchors plus IDs on elements that also have a
> particular class? (or one of a set of classes, or all except those with
> certain classes?) Whatever we determine to be the indicator that there's
> something testable that needs at least one test, that can be our set of
> acceptable link targets.

The current idea is that it would be any ID in the spec except those that
occur within elements of particular classes ('example', 'note', 'no-toc' and
the new 'informative'). Elika's point was that it should be less markup to
exclude non-normative IDs than explicitly define each testable ID as
testable.
 
> Shepherd will be able to help ensure that all <link rel='help'> href's point
> to a known target (it produces a warning on push and files an issue against
> the test if there are links to unknown targets). Here's an example:
> http://test.csswg.org/shepherd/testcase/writing-mode-vertical-lr-002/status/is
> sue/
> (the link is to the property definition.)
> 
> Right now it only knows sections. So for sanity's sake, let say that tests can
> only point to targets other than section headings when the spec has the
> additional conformance markup to determine what the additional legal targets
> areŠ  Let me know the rules to determine the actual link targets and I'll
> build the tool to extract them.

So we could either:

1. Have the tool scan the spec to rule out non-testable IDs using the class
list above, keep track of what IDs fall in which sections, and map the
test's first link to the relevant section (in your example the writing-mode1
link sets the test's section to writing-mode).

2. Require that the first link continue to use section IDs only (in which
case the example might have two links, one to writing-mode and a second to
writing-mode1, if the latter is actually the point of the test and not a
typo).

Received on Tuesday, 6 September 2011 02:41:24 UTC