Re: ReSpec toolchain...

Actually  yes - it is like arguing that.  Our specs need to work offline,
on devices that are basically static.  ePub.  Think about the printers that
support printing data from URIs.  They don't support javascript.  See the
XHTML Print spec for the origins of this technology, although it has gone a
long way since then.

I appreciate your zeal.  But just because we *can* do a thing does not me
we *should*.  It is great that ReSpec helps us create better, more
consistent specs that are more likely to pass pubules.  It is even greater
that it automatically adds things to help with accessibility of our specs,
semantic evaluation of our specs, etc.   It is a tool.  It is not an
end-user delivery vehicle for our specs.  And it shouldn't be.


On Mon, Jul 14, 2014 at 2:35 PM, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On July 14, 2014 at 3:25:35 PM, Shane McCarron (shane@aptest.com) wrote:
> > > I would oppose any movement toward allowing formal W3C specification
> > publications to be dynamically generated in the client.
>
> Wait! that's like arguing that all specs should only be printed on paper
> because computers have moving parts that can break down. Or because the
> network can sometime return you a 404.
>
> The web is a *software platform* - it's not a thing to copy dead trees.
> What you are opposing to is essentially the Web's fundamental features -
> and goes against the whole point of the W3C (to standardize a *software
> platform*).
>
> If we can't publish dynamic content using the technologies that we are
> actually using to build the web platform, then we are failing completely
> here.
>
> The way to address your concerns is to actually fix the loading delays in
> Respec (and to get it to work offline, etc.). That is to say: to treat
> Respec and specs in general like "web applications" and less like dead tree
> carbon copies of some old technology. If Respec is slow on mobile or on
> desktop, we should fix that - not ban publication of dynamic documents
> because the software is a bit buggy.
>
> --
> Marcos Caceres
>