W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2014

Re: Thinking about cross references and ReSpec

From: Shane McCarron <shane@aptest.com>
Date: Thu, 2 Oct 2014 14:11:37 -0500
Message-ID: <CAOk_reFyEOW6S7GuEhvVTbak0HvXjKXQTZkAQmpi9rULmEgB7g@mail.gmail.com>
To: Tobie Langel <tobie.langel@gmail.com>
Cc: Peter Linss <peter.linss@hp.com>, Robin Berjon <robin@w3.org>, "spec-prod@w3.org Prod" <spec-prod@w3.org>
On Thu, Oct 2, 2014 at 1:57 PM, Tobie Langel <tobie.langel@gmail.com> wrote:

> On Thu, Oct 2, 2014 at 7:08 PM, Peter Linss <peter.linss@hp.com> wrote:
>> On Oct 2, 2014, at 4:41 AM, Tobie Langel <tobie.langel@gmail.com> wrote:
>> On Thu, Oct 2, 2014 at 12:10 PM, Robin Berjon <robin@w3.org> wrote:
>>> On 02/10/2014 10:10 , Tobie Langel wrote:
>>>> My plan for this solution is to do daily crawling of relevant specs and
>>>> extract the dfn and put them in a DB. Further refinements could include
>>>> a search API, like I added for Specref and exposed within Respec.
>>> Could you somehow reuse or modify what Shepherd does here? If it
>>> includes enough information (or additional extraction can be easily added)
>>> and new specs can be added to its crawling (which I suspect ought to be
>>> relatively easy — I recall Peter's code being able to process quite a lot
>>> of different documents)
>> Yes, adding specs to it’s crawl is trivial.
>> then we can all align, which I reckon is a win (even without counting the
>>> saved cycles).
>> I've bumped into way too many painful issues with non browser-based HTML
>> parsers to waste more time with them.
>> FWIW, Shepherd uses html5lib and AFAICT sees a browser equivalent DOM
>> which it traverses. This hasn’t been an issue to date.
> So does jsdom[1]. Yet I've bumped into plenty of very annoying issues with
> it (even though jsdom actually has a JS runtime, which afaik html5lib
> doesn't).
>> I'm also very interested in gathering data from editor's draft which
>> requires a JS runtime for those which use ReSpec.
>> At one point I did start to add code to Shepherd’s spec parser (which
>> actually has been completely factored out of Shepherd these days) to handle
>> ReSpec source files. I stopped because ReSpec was under heavy development
>> at the time and I didn’t want to chase a moving target.
>> Finishing this wouldn’t be that big a deal (and would be made easier if
>> ReSpec uses the Bikeshed dfn markup).
>  Unfortunately, I need a solution that works for ReSpec drafts right away.

I would prefer that too - something where my draft can push its definitions
in (with credentials maybe, and on demand, not automatically, through the
save menu?) and correspondingly access them from the related drafts
automatically is what I am looking for.

 Honestly, this feels like a solved problem.  I would be happy to take a
stab at implementing the bikeshed syntax in ReSpec as a way of getting this
started.  I find the bikeshed extensions really compelling.
Received on Thursday, 2 October 2014 19:12:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:20 UTC