RE: ACTION: elaborate on 4.4

-------- Original Message --------
> From: Kendall Clark <>
> Date: 18 June 2004 17:48
> 
> On Fri, Jun 18, 2004 at 05:34:23PM +0100, Seaborne, Andy wrote:
> 
> > That really only makes sense if the non-XML serializations are common.
> 
> Well, how high is up? All of our (UMD) tools take N3 as input. Is that
> common enough?

As do ours.  However, our own local preferecnes are enough on their own to
justify this WG getting involved.  Some of the issues are more bound to
registering MIME types and the time/work that takes.

If we can find a way to have an extensible "Accept:"-like scheme that used
URIs then that presumably would meet your need for the design goal?

> 
> > Otherwise, the set up client/server has a dependency in assuming some
> > format is available.  I suppose use(abuse? not sur eit is correct
> > use) of OPTIONS is possible.
> 
> I think it's a use, not an abuse, but then I support it, so I would
> think that. :>
> 
> > > Sorry, but "one ring to bind them"-style arguments fall super flat
> > > with me. Standardization != restriction of choices to 1 only.
> > 
> > We would, I presume, require that at least RDF/XML is supported as a
> > serialization format for reasons of maximum interoperability.
> 
> I totally agree with this. No one would be *required* to support
> anything other than RDF-XML. I just want to enable clients & servers
> that want to support something else to do so cleanly.
> 
> As I've said, if there can be only one XML serialization, RDF-XML is
> the one. I just haven't yet heard a convincing argument for that
> premise. Appeals to "standardization" are neither convincing nor
> useful, IMO.
> 
> > Where
> > additional features (e.g. named graphs) are needed then fine.
> 
> Additional features:
> 
> 1. non-XML formats (NTriples, YAML)
> 2. human factors (N3, Turtle)
> 
> No one makes up new serialization formats for *no* reason -- well,
> except Dave Beckett. He's crazy! :>
> 
> >  It's
> > encouraging the alternative serializations of core RDF where I don't
> > understand the need for a requirement.
> 
> Well, this is a design objective. And I'm not encouraging them. I'm
> trying to recognize and accomodate *existing practice* on the
> ground. That is a perfectly legitimate role of standardization work,
> one of many such goals.
> 
> > Generally, I don't expect people to look at the results of a DAWG
> > query directly - the output is consumed by some client-side
> > application - so I don't put much weight on the need for alternative
> > serializations. 
> 
> But, Andy, that assumes a premise I have no reason to believe, namely:
> "The only reason for an alternative serialization format is to enable
> human consumption".
> 
> That's just wrong as a reading of the factual reasons that people
> offer for alternative serializations.
> 
> Best,
> Kendall
> 
> PS--Sorry if this sounds harsh; I'm feeling sick today and generally
> malaiseful.

Received on Friday, 18 June 2004 13:25:14 UTC