Re: Preparing editor's drafts -- Q's for the team contacts

* Richard Cyganiak <richard@cyganiak.de> [2011-05-25 11:41+0100]
> On 25 May 2011, at 11:34, Ivan Herman wrote:
> > Ah, sorry, I misunderstood you. However.... (and here comes my ignorance with Mercurial): why do we need anything else than the Mercurial repository then? 
> > 
> > The practical issue is that if we define a directory under /2011/rdf for this, that area _is_ a CVS tree. Ie, editors would use CVS to update that directory. But, if so, why do we need Mercurial again?
> > 
> > (B.t.w., the RDFAWG uses CVS, so does the rdb2rdf and sparql groups. I would still have to understand what Mercurial brings us extra, apart from being more trendy...)
> 
> This is a cruel question. The only way to authoritatively answer it is by reliving a decade of traumatic memories. ;-)

If I understand correctly, mercurial has a more ambitious conflict resolution scheme (attempting each incremental patch constituting the document to be merged). This can accurately eliminate some conflicts.
Mercurial's conflict resolution path used to require an odd to tell the system that the conflict is indeed resolved postponed conflicts (say, after you edit the <<<===>>>s). I don't know if that's still an issue.

Having worked with both, I have a marginal preference for Mercurial, but I want to caution Richard not to assume that a new administration will treat the prisoners much better.


> Richard
> 
> 
> 
> 
> > 
> > Ivan
> > 
> > 
> > 
> >>> 1. We aim at a set of documents that fully and absolutely supersede the old documents. This means we'd continue to use the http://www.w3.org/TR/rdf-concepts/ for what we call the 'short URI' in our document management jargon with, of course, the 'dated URI-s' reflecting the current date. This means that, in future, if somebody uses the short uri as a reference, he/she will fall on the new version of the document.
> >> 
> >> I am in favour of that.
> >> 
> >>> Note that this may lead to some disruptions during the development process when users will suddenly find themselves reading working drafts. As an example, this is what the xml guys did: the http://www.w3.org/TR/xml/ URI leads to the latest (5th edition as of today) of XML.
> >> 
> >> I am *not* in favour of that. Some of the documents will go through a certain amount of churn, and the new features like multigraph might be in a rough state for a while, and I would not like people looking for a W3C REC to be presented with work in progress.
> >> 
> >>> I guess it may be possible to use a short name for the development time and change this on the last minute to switch to the old names
> >> 
> >> This sounds like a good solution to me.
> >> 
> >>> but I would not favour that, personally; it may become messy on long run.
> >> 
> >> What exactly is the concern?
> >> 
> >>> If we adopt a numbering (like the SPARQL and OWL have done), then we would probably use a different short name. If we just go for a 'second edition' then the XML approach might be the winning one.
> >> 
> >> I thought a bit more about this.
> >> 
> >> I guess we're going to want to say things like: “RDF (old) didn't have multiple graphs, but RDF (new) does.” Or “In RDF (old) this would have been two triples, but in RDF (new) it's just one.” Saying “first-edition RDF” and “second-edition RDF” doesn't seem quite right for something that actually includes relevant new features. Saying “RDF 1.0” and “RDF 1.1” seems more appropriate. So my vote is for RDF 1.1.
> >> 
> >> Thanks,
> >> Richard
> > 
> > 
> > ----
> > 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
> > 
> > 
> > 
> > 
> > 
> 
> 

-- 
-ericP

Received on Wednesday, 25 May 2011 12:43:58 UTC