RE: Shared references service

Hi Robin.

Thanks for this (he said, delighting in the consistency that we now have).

>From a functional perspective, are there any changes for the way that an editor would use the references in a spec, or does ReSpec continue inserting references using the same format-- [[!ECMA-262]] for example--merely drawing from a different source?

Thanks,

Eliot

> -----Original Message-----
> From: Robin Berjon [mailto:robin@berjon.com]
> Sent: Friday, June 22, 2012 7:01 AM
> To: David Carlisle
> Cc: spec-prod Prod
> Subject: Re: Shared references service
> 
> Hi David,
> 
> On Jun 22, 2012, at 15:31 , David Carlisle wrote:
> > For those of us using xmlspec, I don't suppose you could offer xml as
> > well as json? It doesn't make it much easier but it might make it a
> > bit
> > easier: the json parsing in the following is a bit flaky and it would
> > probably be easier for the server just to serve the structure it had?
> 
> If it means more people using the service, and more people contributing to
> maintaining the DB, then I certainly could!
> 
> If I did, would you want me to use the same syntax you exemplified? I can think
> of simpler ones, but I don't know what your exact needs are.
> 
> One potential problem is that a non-negligible number of the references don't
> (yet) have the nice title/href/authors/publisher split fields but rather just have
> an html field that contains the pre-rendered reference (they're being phased
> out, but I still see 890 such references versus 5491 in the new style). There is no
> guarantee that those are well-formed for XML consumption (most probably
> are, but it's not guaranteed). So the safe thing to do there would be to return
> those in a CDATA section - but I don't know how helpful that would be to you.
> The alternative is to not return those at all.
> 
> > If not, the json parsing could of course be improved, this is just a
> > quick test of your server:).
> 
> Yeah, in general I have to say that I don't think it's very practical for
> XSL/XQuery not to have native JSON support ;-)
> 
> > I note that q=MATHML returns the latest MathML draft in TR. I don't
> > really mind but the notes imply it perhaps ought to return the
> > editors' draft (or there should be another ID that returns the
> > editors' draft?) which would be
> >
> > https://www.w3.org/Math/Group/draft-spec/
> > rather than
> > http://www.w3.org/TR/MathML/
> 
> As indicated in the notes (but perhaps not clearly enough) the idea is that what
> should be returned ought to be the "latest and greatest". The exact
> interpretation of that is entirely left up to whoever inserts that reference.
> Sometimes the ED is far ahead and better maintained than the TR version,
> sometimes the ED can be a big mess and there are frequent cleaner snapshots
> in TR.
> 
> If you think that the ED makes more sense for MathML, I strongly encourage
> you to give me your GitHub ID so that I can add you as a contributor and you
> can make the change ;-)
> 
> (If you're really lazy, I'll do it though.)
> 
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
> 
>

Received on Friday, 22 June 2012 15:19:15 UTC