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 07:33:31 -0500
Message-ID: <CAOk_reFTNaewHOjXWKYWWjW92wpQM6a+F2X7CTk+4LFTkHvUQQ@mail.gmail.com>
To: Tobie Langel <tobie.langel@gmail.com>
Cc: Robin Berjon <robin@w3.org>, "spec-prod@w3.org Prod" <spec-prod@w3.org>
On Thu, Oct 2, 2014 at 7:24 AM, Tobie Langel <tobie.langel@gmail.com> wrote:

> On Thu, Oct 2, 2014 at 2:18 PM, Shane McCarron <shane@aptest.com> wrote:
>
>> On Thu, Oct 2, 2014 at 7:15 AM, Tobie Langel <tobie.langel@gmail.com>
>> wrote:
>>
>>> On Thu, Oct 2, 2014 at 1:49 PM, Shane McCarron <shane@aptest.com> wrote:
>>>
>>>>
>>>>
>>> As an aside, I note that the SpecRef lookup (in ReSpec biblio.js) uses
>>>> https GET.  I would change that to POST so that if there is a huge query we
>>>> don't overflow URL length limits.  I will create an issue about it.
>>>>
>>>
>>> The effective limit is around 2000 chars[1] which should give us over a
>>> hundred references. Let's think about fixing it when we cross it, no?
>>>
>>
>> If you insist.  Is the service not able to handle POST requests?
>>
>
> Not sure (think I probably purposefully limited it to GET when building
> the service, but that's easy to change).
>
> I only mentioned it because if we are integrating definition cross
>> reference lookups, we could easily overflow the limit.
>>
>
> That would probably be two different end-points, no?
>

Probably.  I don't know what you had in mind for design.  I expect it is a
different XHR call - no need to conflate them as they are in very different
portions of the ReSpec implementation.

On the other hand, if we wanted to limit the number of XHR round trips, we
could delay the resolving of definition references until late in processing
- make a single call, get the bibliographic AND definition cross reference
links in a single call, then make the updates to the document.  That might
be bad, unmodular design, but it might speed up processing for large
documents.

In any event, I will leave it alone for now.
Received on Thursday, 2 October 2014 12:33:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:21 UTC