W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2010

Re: ACTION-11 Proposed Short Names

From: Ivan Herman <ivan@w3.org>
Date: Sat, 27 Feb 2010 09:05:42 +0100
Message-ID: <4B88D256.6010103@w3.org>
To: Shane McCarron <shane@aptest.com>
CC: RDFa WG <public-rdfa-wg@w3.org>

just small comments; for everything else I am in agreement with the

On 2010-2-26 21:12 , Shane McCarron wrote:
> I had an action to propose some short names for our specs.  Before I do
> that, a reminder that at the W3C specs are generally organized like this
> (at least when I have been the editor):
> short-name /
>   Overview.html   - the main spec page (could be the whole spec)
>   short-name-diff.html   - diffs from previous version if any
>   short-name-rec.html    - diffs from a previous recommendation if any
>   short-name.ps|pdf      - postscript / PDF versions of the spec if any
>   short-name.css         - any local styles
>   images /               - any embedded images (SVG, PNG, etc.)
>   DTD | SCHEMA | RELAX / - any schema implementations
>   js /                   - any script implementations
>   short-name.zip|tgz     - archive of everything that is downloadable

For those of you who are new in the W3C process: 'publication' means to
move the content of these directories to a central place. Ie, the
current RDFa rec is physically stored in the


which is a directory in the file system. The 'short name', ie,


is, again on the server, just a link to the latest version of the document.

What Shane proposes is to have our own copy at one place where we could
work, see below.

I practical comment, though. There has always been a question in the
past whether DTD-s or namespace documents or the like should be part of
the core distribution as stated above. If a DTD gets stored in /TR space
then, according to W3C rules, they cannot be touched any more even if
the problem is just a stupid and obvious mistake. If the DTD is stored
somewhere else, such changes become easier. The same with RDF
vocabularies and the like. I wonder whether we should not treat them
separately from the start.

Also: we may have to have separate namespace documents for RDFa (eg, for
small RDF vocabularies). Those may be stored separately these days as

> As to short names, my suggestions are:
> RDFa Core 1.1 - rdfa-core
> XHTML+RDFa 1.1 - xhtml-rdfa
> RDFa API - rdfa-api
> RDFa Primer - rdfa-primer (replaces xhtml-rdfa-primer)
> RDF TripleStore APIs - rdf-triple-api
> RDFa Usage Cookbook - rdfa-cookbook
> Finally, in terms of structure on W3C's server in the RDFa area, I propose:
> 2010/02/rdfa/
>   drafts/          - place where drafts for public consumption are dropped
>      Overview.html - file that lists the documents in progress and has

I'd prefer to use the Wiki for such lists rather than a separate HTML
file. Remember the Wiki is, by default, editable to everyone in the
group and does not need an additional CVS access (the latter will be set
up for all editors but not necessarily for others).

Ie, there should be a Wiki page with a table of the history for each
document as well a pointer to the latest editor's draft.

> links to the latest
>      2010/         - folder for each year
>        ED-short-name-date/  - folder for each published ED

I actually wonder whether it is worth storing the previous drafts under
the rdfa tree. After all, once a draft is published, we are not supposed
to touch it; for historical purposes the W3C publication process does
make a copy anyway. So why storing duplicata?

I presume the XHTML WG did that; the SPARQL or OWL WG did not. I would
like to understand the thinking behind it...

>   sources/
>      short-name/   - folder for each document in development
> This completes ACTION-11.


Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf

Received on Saturday, 27 February 2010 08:05:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:16 UTC