Re: Feeling stupid about references

I said 'gross' because I had a visceral reaction to doing it this way.  I
should preface this by saying that I do testing for a living.  And I have
for more than 30 years.  I know this is old school, but "If it's not the
same, it's different".

If it is in the repository and is referenced from the repository by all the
publications that need the reference, then there is a single source.  It is
the same.  If it is put in the source locally, even as an interim solution,
there is the potential for divergence.  We were updating 4 specs with 3
different editors.  It is easy to see how there might be subtle differences
introduced in the documents.  Then static versions are created and those
static versions have those subtle differences in them forever.  In TR
space.  That is bad.

Do I have a better suggestion?  Well, in most cases I would just update the
repository and reference it.  The repository is ONLY used by live, evolving
documents anyway.  Editor's Drafts and the like.  Nothing in TR space uses
ReSpec, so changing the repository does not effect published specs.

The obvious down-side to this approach is that it is hard to have the
automatic generation of the repository data.  If a change precedes the
publication (as I attempted to do earlier this week) and the automatic
generation then comes in and overwrites it with old data, that would be
bad.  It would also be bad if a manual edit were inconsistent with whatever
the automatically generated content would look like (e.g., I make an edit,
use those references in a published spec, then post-publication the data is
updated from the real document automatically and it is (subtly) different).

So... here is my suggestion. Obviously continue to permit local entries.
 Careful, smart people will be able to get those right.  But also enable a
way to tell the automated extraction system that the source of a new
version is temporariliy *over here* - not yet in TR space.  Enable this as
a service so we can say "please augment the repository with updated
reference information for spec X from location Y".  Potentially also saying
"this temporary location will be no longer valid after DATE".  And of
course permit this to be done repeatedly if the spec author makes mistakes
(I am probably the only author who ever makes mistakes, but it would surely
help me).

I know this would require the repository system to me more sophisticated,
and I am more than willing to help implement this.  I think it would be a
better way than local definitions.  It would also mean that the source of
FINAL versions of specifications would not need to be edited again to
remove the local definitions after the referenced spec is actually
published.

Thoughts?


On Thu, Jun 20, 2013 at 10:35 AM, Tobie Langel <tobie@w3.org> wrote:

> Find that gross? I'm all ears for a better solution. Using localBiblio in
> that case seemed like the most lightweight option.
>
> Concerning the pull request, let me get back to you separately. TR/ is
> being completely revamped, and I'm hoping that we should be able to
> completely automate all W3C specs including the ones which aren't sourced
> for now.
>
> --tobie
>
>
> On Thursday, June 20, 2013 at 5:03 PM, Shane McCarron wrote:
>
> > Gross. Does that mean I should cancel the pull request I just submitted?
> >
> >
> > On Thu, Jun 20, 2013 at 10:02 AM, Tobie Langel <tobie@w3.org (mailto:
> tobie@w3.org)> wrote:
> > > In that case, the best solution is to use a local biblio[1] for those
> three until you publish.
> > >
> > > --tobie
> > >
> > > [1]:
> http://lists.w3.org/Archives/Public/spec-prod/2012OctDec/0031.html
> > >
> > >
> > > On Thursday, June 20, 2013 at 4:43 PM, Shane McCarron wrote:
> > >
> > > > rdfa-core, xhtml-rdfa, and html-rdfa are all changing state next
> week. But of course they are inter-dependent and we need to generate them
> now so we can pubrules check etc.
> > > >
> > > >
> > > > On Thu, Jun 20, 2013 at 9:39 AM, Tobie Langel <tobie@w3.org (mailto:
> tobie@w3.org) (mailto:tobie@w3.org)> wrote:
> > > > > It's going to get overwritten the next time we sync.
> > > > >
> > > > > Currently sync is manual, but is done frequently (once a week or
> so).
> > > > >
> > > > > Some specs are in a little bit of a mixed state right due to
> issues in TR/ which are in the process of getting fixed. Which sourced
> specs would you need to update?
> > > > >
> > > > > --tobie
> > > > >
> > > > >
> > > > > On Thursday, June 20, 2013 at 4:33 PM, Shane McCarron wrote:
> > > > >
> > > > > > That's helpful - thanks. I note that some things say the source
> is the tr.rdf document from the W3C. If I update an entry that was sourced
> from there by hand what hapens?
> > > > > >
> > > > > >
> > > > > > On Thu, Jun 20, 2013 at 8:59 AM, Markus Lanthaler <
> markus.lanthaler@gmx.net (mailto:markus.lanthaler@gmx.net) (mailto:
> markus.lanthaler@gmx.net) (mailto:markus.lanthaler@gmx.net)> wrote:
> > > > > > > Hi Shane,
> > > > > > >
> > > > > > > On Thursday, June 20, 2013 3:47 PM, Shane McCarron wrote:
> > > > > > > > I am trying to update a couple of specs today. In the
> process I am
> > > > > > > > switching them over to the Latest ReSpec at the W3C. I also
> need to
> > > > > > > > update a couple of references that these specs use, and of
> course
> > > > > > > > update the central collection of references *about* these
> specs so
> > > > > > > > that other things that reference them reference the right
> thing....
> > > > > > > >
> > > > > > > > What is the current best practice for doing this?
> > > > > > >
> > > > > > > The biblio DB has been moved to this repository:
> > > > > > >
> > > > > > > https://github.com/tobie/specref
> > > > > > >
> > > > > > > Look for the bilbio.json file
> > > > > > > (https://github.com/tobie/specref/blob/master/biblio.json),
> edit it and
> > > > > > > finally open a pull request.
> > > > > > >
> > > > > > >
> > > > > > > Hope this helps
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Markus Lanthaler
> > > > > > > @markuslanthaler
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Shane P. McCarron
> > > > > > Managing Director, Applied Testing and Technology, Inc.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Shane P. McCarron
> > > > Managing Director, Applied Testing and Technology, Inc.
> > >
> >
> >
> >
> >
> > --
> > Shane P. McCarron
> > Managing Director, Applied Testing and Technology, Inc.
>
>
>
>


-- 
Shane P. McCarron
Managing Director, Applied Testing and Technology, Inc.