headers
Denis Ah-Kang | 4 Jun 2013 01:01
Picon
Favicon

Heads-up: Upcoming changes in the publication system backend and tr.rdf

Hi everyone,

As you know, we are currently rewriting the publication system backend.
We are targeting a deployment in two or three weeks.

As plh said [1]:
[[
there will be no visible change from the point of view
of the editors and our site users. The main change will be in the back
end. However, the new DB will be a lot more flexible and will allow us
to add new information more easily.
]]

Main points:
* the primary data source is no longer tr.rdf [2] but a MySQL database
* tr.rdf is dynamically generated from the database (see [3] for an example)

Because of some inconsistencies in the RDF data, we expect a few spec
histories to be incomplete because of the migration to MySQL (some date
back to 1996!). Note that it will be easy to fix them as you report such
problems.

Denis

[1] http://lists.w3.org/Archives/Public/spec-prod/2013AprJun/0024.html
[2] http://www.w3.org/2002/01/tr-automation/tr.rdf
[3] http://www.w3.org/2013/06/tr_sample.rdf
Permalink | Reply | 1 comment |
headers
Henry S. Thompson | 3 Jun 2013 16:00
Picon
Picon
Favicon

Please don't shout or throw things at this respec newbie

I prefer to edit my specs in XML.  I have a usable respec+XHTML source
doc't, which previews correctly in browsers.  Or, rather, I thought I
did.

It works with specStatus="unofficial", but not with specStatus="ED".
In the later case, it fails (Chrome, Opera) with "DOM Exception 12"
(Chrome), "DOMException: SYNTAX_ERR (Opera, which shows a stack trace
with

  Error thrown at line 3, column 165069 in <anonymous function:clean>(e, t, n, r) in
http://darobin.github.com/respec/builds/respec-w3c-common.js:
    t===_?Lt.appendChild(p):x(t).appendChild(p),p.innerHTML=c[1]+f+c[2];)

I'm using

  http://www.w3.org/Tools/respec/respec-w3c-common

which is, as is evident above, obfuscated, so debugging is,
essentially, impossible.

Is there a non-obfuscated version I could be using to get more useful
insight into what's wrong?  Anyone recognise this problem?

Thanks,

ht

[BTW, if I use tidy5 to convert
http://darobin.github.io/respec/docs/template.html to XHTML5, it gives
the same error, so I don't _think_ this is the result of some actual
(Continue reading)

Permalink | Reply | 20 comments |
headers
Marcos Caceres | 30 May 2013 13:06
Gravatar

Re: Update on the publication process project


On Friday, 24 May 2013 at 18:26, Gregg Kellogg wrote:

> On May 24, 2013, at 5:49 AM, Tobie Langel <tobie <at> w3.org (mailto:tobie <at> w3.org)> wrote:
> 
> > Hacked a script that pulls tr.rdf data and turns it into palatable JSON. 
> 
> Another way to do this would be to transform the RDF to JSON-LD and frame it appropriately. This would yield
much the same results, but would use standardized processes, and maintain the references as linked data
in JSON.
> 

Could also work, but we need someone to do the work. Maybe the RDF generation code can be moved to GH. At least
we could look at it and we would have a higher chance of having someone fix it.  

--

-- 
Marcos Caceres
Permalink | Reply | 1 comment |
headers
Tobie Langel | 24 May 2013 19:55
Picon
Favicon

Re: Update on the publication process project


On Friday, May 24, 2013 at 7:26 PM, Gregg Kellogg wrote:

> On May 24, 2013, at 5:49 AM, Tobie Langel <tobie <at> w3.org (mailto:tobie <at> w3.org)> wrote:
> 
> > Hacked a script that pulls tr.rdf data and turns it into palatable JSON. 
> 
> Another way to do this would be to transform the RDF to JSON-LD and frame it appropriately. This would yield
much the same results, but would use standardized processes, and maintain the references as linked data
in JSON.
I'm sure there are more correct ways of doing this than I did. But this was working within minutes and serves
our purpose perfectly.

--tobie
Permalink | Reply | 0 comments |
headers
Marcos Caceres | 23 May 2013 21:18
Gravatar

Let's update the Respec documentation!

Hi Respec Users,

Robin and I are trying to organize a doc sprint to update the Respec documentation [1] and we would really
like some help. If this is something you could help with, check out this bug:

https://github.com/darobin/respec/issues/224

In the first pass, we want to reorganize the docs (what we already have, how to split the docs into smaller,
clearer bits) and capture that on GitHub.

If you've been using Respec for a while, this is a chance for you to give a little back :) You might also learn a
few new undocumented tricks/features.

[1] http://dev.w3.org/2009/dap/ReSpec.js/documentation.html

PS: Sorry if you get this email twice. 
--

-- 
Marcos Caceres
Permalink | Reply | 5 comments |
headers
Robin Berjon | 22 May 2013 15:13
Picon
Favicon

ReSpec using external references service is now live

Dear all,

it's something that we tinkered with several times, but that has finally 
been done and enabled (by Tobie — thanks!). Instead of shipping with its 
references database, ReSpec now consults an external service.

This has several implications:

• The code size that goes over the wire has dropped from 150k to 88k. 
That's a 42% drop. On a decent network, the FOUC is almost gone.

• If you were doing some monkey-patching of the references system in 
spite of multiple warnings that it will break, then the odds are good 
that you have breakage. Last I checked most people had stopped doing 
that so I hope things are okay.

• You can still have references private to your draft using localBiblio.

• When you want to make a change to the references, the place to do so 
is now: https://github.com/tobie/specref. This still requires editing 
the JSON file (for now). But the big advantage is that there is now no 
need to wait for a ReSpec build before your change will show up. As soon 
as a pull request is accepted, assuming you didn't break the JSON (the 
file is tested first), then the new entries are automatically deployed 
to http://specref.jit.su/.

• This includes all the goodies that Tobie and Marcos have been adding 
(structured references, aliases, support for previous dated versions, etc.).

Let me know if something breaks!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philippe Le Hegaret | 20 May 2013 18:08
Picon
Favicon

Update on the publication process project

Hi folks,

some of you may remember the TPAC session we had last year on the
publication process, ie pubrules and /TR. Here is an update on some of
our (small) progress.

Denis, who is spending his last weeks with us, has been working on
rewriting from scratch a good chunk of our back end tools for
publication. The current tools are basically ancient and are getting
more and more unusable. As such, he came up with a new DB to maintain
all the information on /TR documents and is currently trying to get it
up and running before his departure. The difficulty was to represent all
the corner cases the webmaster faces when handling publications.

Once he is done, there will be no visible change from the point of view
of the editors and our site users. The main change will be in the back
end. However, the new DB will be a lot more flexible and will allow us
to add new information more easily. One of the information that I'm
interested in exposing is the links to editor's drafts, which will allow
us to generate a version of /TR with them. We'll get the links directly
from the documents so, again, no additional step needed from the
editors.

Regarding generating a new /TR page, it appeared clearly at TPAC that
the current version wasn't being used much by the W3C experts, mainly
due to its painful interface. Even if it is dangerous to extrapolate
from just one single session, I suspect that the feeling is relatively
general in W3C. The old /TR page was a simple list of the documents but
was getting quite long. My thinking has been that we may need a simple
TR page for the W3C community, which allows fast search/navigation, and
(Continue reading)

Permalink | Reply | 16 comments |
headers
Richard Ishida | 7 May 2013 14:05
Picon
Favicon
Gravatar

Respec bugs

Annoyingly I have to keep fixing a couple of bugs while trying to 
publish a FPWD of a document intended to become a WG NOTE. Where should 
I report them?

I'll report here for the time being.  Spec status was set to FPWD-NOTE.

[1] Status boilerplate:

"This document was published by the Internationalization Working Group 
as a First Public Working Group Note"

is ambiguous. I think respec should generate:

"This document was published by the Internationalization Working Group 
as a First Public Working Draft. The group intends to publish this 
document as a Working Group Note"

[2] Pubrules gives the following error:

"Error. The W3C style sheet should be 
http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE. It is currently 
//www.w3.org/StyleSheets/TR/W3C-WG-NOTE. "

RI

--

-- 
Richard Ishida, W3C
http://rishida.net/
(Continue reading)

Permalink | Reply | 10 comments |
headers
Marcos Caceres | 2 May 2013 12:48
Gravatar

New Respec feature: support for additional links in header

Hi,   
I've created a new feature for Respec that allows custom links at the head of a document. The new property is
called "otherLinks", and takes an array of objects as content. For example:
...
otherLinks: [
{  
key: "Test Suite",  
href: "https://w3.org/..."  
},

{  
key: "Spec updates",
value: "follow our  <at> working_group on the twitter"
href: "https://twitter/working_group"  
}

]
...

I've detailed how it works here:  
https://github.com/darobin/respec/pull/208

Would appreciate any suggestions you might have … specially if you think it could be made easier to use,
etc.   

Thanks!  
--  
Marcos Caceres
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcos Caceres | 1 May 2013 19:27
Gravatar

Removed some redundancy for biblio.js

In the current biblio.js, there are quite a few repeated entries that only differ by key. For example,  

    "FLEXBOX": {
        "authors": [
            "Tab Atkins Jr",
            "Elika J. Etemad",
            "Alex Mogilevsky"
        ],
...
    },
    "FLEXBOX-20120918": {
        "authors": [
            "Tab Atkins Jr",
            "Elika J. Etemad",
            "Alex Mogilevsky"
        ],
...
    }

I would like to propose adding a "previousVersions" property, which contains the URLs to previous
versions of a spec.  

The previousVersions property would have the following data structure:  
[{datekey: "20121213", url: "http://w3/TR/..."}]

Then, people who want to refer to a dated version of a document in their spec:
<p>The [[FOO-20121213]] spec … bla bla bla</p>  

And the link to the dated spec is put into the bibliography at the end of the document.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kostiainen, Anssi | 16 Apr 2013 11:08
Picon
Favicon

[respec] 'noLegacyStyle' config flag

[ +cc spec-prod, +bcc public-sysapps ]

Hi Eduardo,

On Apr 11, 2013, at 4:07 PM, EDUARDO FULLEA CARRERA <efc <at> tid.es> wrote:

> Can you please give me a pointer to the ReSpec flag that avoids the redundancies in the resulting HTML?

Here's the pointer:

  http://lists.w3.org/Archives/Public/spec-prod/2013JanMar/0006.html

And this is how the source of the example spec looks like:

  https://dvcs.w3.org/hg/dap/raw-file/default/proximity/Overview.src.html

If you set this flag, you should move any relevant prose from Attributes and Methods sections below the IDL
blocks. This makes the ReSpec-authored specs look more like the ones authored using Anolis. I think this
improves the readability of specs.

-Anssi
Permalink | Reply | 0 comments |

Gmane