W3C home > Mailing lists > Public > public-csv-wg@w3.org > April 2014

Re: Request for comments - Requirements analysis

From: Jeni Tennison <jeni@jenitennison.com>
Date: Tue, 29 Apr 2014 14:30:31 +0100
To: Eric Stephan <ericphb@gmail.com>
Cc: "Ceolin, D." <d.ceolin@vu.nl>, Ivan Herman <ivan@w3.org>, W3C CSV on the Web Working Group <public-csv-wg@w3.org>
Message-ID: <etPan.535fa977.75a2a8d4.7cc7@jenit.local>
The Requirements in the Use Cases work are requirements on us as a working group to provide some level of specification around a particular issue, not on applications.

For example, "R-URIMapping” talks about the ability to map values to URLs. That means that we (the Working Group) have to document how someone can define what URL a value maps to. It doesn’t mean that all applications have to be able to perform that function, though we might say that there are conforming applications of particular types (eg those that map to RDF) that must be able to understand that property.

Hope that helps,

Jeni

------------------------------------------------------
From: Eric Stephan ericphb@gmail.com
Reply: Eric Stephan ericphb@gmail.com
Date: 29 April 2014 at 14:15:31
To: Jeni Tennison jeni@jenitennison.com
Cc: Ceolin, D. d.ceolin@vu.nl, Ivan Herman ivan@w3.org, W3C CSV on the Web Working Group public-csv-wg@w3.org
Subject:  Re: Request for comments - Requirements analysis

> Would using the terms "core requirement" and "optional requirement"
> be useful? I'm just thinking that future applications might wish
> to incorporate some additional requirements, but it doesn't create a
> burden for every application to be compliant to these requirements.
>  
> Eric
>  
> On Tue, Apr 29, 2014 at 1:19 AM, Jeni Tennison wrote:
> > I think the categorisation should be:
> >
> > 1. This is not a real requirement or is best merged with another requirement (in which  
> case remove it from the Use Cases document)
> >
> > 2. This is a real requirement but is either low priority or too complex so we are not going  
> to handle it during the chartered lifetime of the group (list it in the Use Cases document  
> as Deferred or For Later or something similar)
> >
> > 3. This is a real requirement that we need to make sure we address in the documents we produce  
> (list it in the Use Cases document as an Accepted requirement)
> >
> > Jeni
> >
> > ------------------------------------------------------
> > From: Ivan Herman ivan@w3.org
> > Reply: Ivan Herman ivan@w3.org
> > Date: 29 April 2014 at 09:04:16
> > To: Ceolin, D. d.ceolin@vu.nl
> > Cc: W3C CSV on the Web Working Group public-csv-wg@w3.org
> > Subject: Re: Request for comments - Requirements analysis
> >
> >> Davide,
> >>
> >> thanks.
> >>
> >> I do have a more general issue, though, something that I already touched upon in [1]:  
> what
> >> does it mean for us as a group to say that a requirement is 'accepted'. I could see different  
> >> meanings:
> >>
> >> 1. The requirement is valid, in the sense that it is clear what it means, and there are  
> a
> >> number of data out there that carry this feature
> >> 2. Like #1 and, additionally, the WG will consider that item to be a necessary feature  
> >> to be fully incorporated in everything we do (CSV+, metadata, conversion to other  
> formats)
> >> 3. Like #1 and, additionally, the WG will consider that item to be mostly necessary,  
> and
> >> a 80/20 cut has to be considered whether that feature is incorporated in CSV+, in CSV->JSON,  
> >> etc.
> >>
> >> This discussion came up (in [1]) in relations with the microsytax and its handling  
> in
> >> an RDF conversion. If the usage of microsyntax is widely used out there, ie, it is in  
> the
> >> 80 of the 80/20 cut, then we probably should put energy into a universal solution for  
> the
> >> RDF conversion. However, if it is only in the '20', then we may decide to ignore this  
> (at
> >> least in this version), or delegate it to the vague aspect of external machine (JS callback,  
> >> SPARQL whatever), ie, leave it to the user.
> >>
> >> I think we should have a clear idea of what we are doing at this point without making decisions  
> >> that would bite us later... My feeling is that we need a finer categorization, and not  
> >> only a binary one.
> >>
> >> Thoughts?
> >>
> >> Cheers
> >>
> >> Ivan
> >>
> >> [1] http://lists.w3.org/Archives/Public/public-csv-wg/2014Apr/0101.html  
> >>
> >> On 28 Apr 2014, at 17:38 , Ceolin, D. wrote:
> >>
> >> > Hi all,
> >> >
> >> > Eric, Jeremy and I had a first round of comments about the requirements and came up  
> with
> >> a series of proposal, nicely organized by Eric. Please find them on github (in CSV or  
> CLS
> >> format):
> >> >
> >> > https://github.com/w3c/csvw/blob/gh-pages/use-cases-and-requirements/csvw-requirements-notes.csv  
> >> >
> >> > https://github.com/w3c/csvw/blob/gh-pages/use-cases-and-requirements/csvw-requirements-notes.xls  
> >> >
> >> > Since we would like to have your opinions, to facilitate commenting, I've also ported  
> >> the CSV on the wiki (I hope not to create troubles due to duplication of resources):  
> >> >
> >> > https://www.w3.org/2013/csvw/wiki/Requirements_analysis
> >> >
> >> > We look forward to hearing what you all think,
> >> >
> >> > Davide
> >>
> >>
> >> ----
> >> Ivan Herman, W3C
> >> Digital Publishing Activity Lead
> >> Home: http://www.w3.org/People/Ivan/
> >> mobile: +31-641044153
> >> GPG: 0x343F1A3D
> >> FOAF: http://www.ivan-herman.net/foaf
> >>
> >>
> >>
> >>
> >>
> >>
> >
> > --
> > Jeni Tennison
> > http://www.jenitennison.com/
> >
>  
>  
>  

--  
Jeni Tennison
http://www.jenitennison.com/
Received on Tuesday, 29 April 2014 13:30:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:39 UTC