… if we had had more WG interest/expertise in this area, we might have gone deeper. Can put it on the list for 'if we get rechartered…'

jtandy: but we can discuss the union datatypes

… he says union datatypes don't address his problem

<JeniT> https://github.com/w3c/csvw/issues/223

#223 also

gkellogg: there's a complexity on the implementations that is at this point a major barrier. Adding this right now would be troubling for fledgling implementations.

… there are other ways to consider getting in multi-typing info

… the union types does address the same problem but not in his preferred manner

jenit: I agree. I'll go back to him on the xsd schemas aspect, to try to get to the bottom of it. But I don't think we need a lot more discussion here - we have some consensus.

jtandy: he could flesh it out and try to show how it would work

gkellogg: there are 2 aspects, … one is requirement that you implement the default xsd mechanism. The other is providing space to allow an unanticipated datatype.

Where the base could be say an IRI or a compact IRI or URI instead of one of our predefined tokens. That presumably could be added without too much pain.

jtandy: that doesn't support validation though?

gkellogg: it supports it to degree we support it for anything beyond time/numbers/booleans.

…(regex something)

jenit: if we want to support that, and it is quite a nice idea, having specialized datatypes which have names (URIs), … useful in both XML and RDF. If so, the way we should do that is an @id on the datatype …

gkellogg: but we have a field, it is the baes

base

jenit: that is different

… base tells you what kind of datatype, eg. Integer -> age

… min/max etc

jenit: having @id on datatype and using that within RDF (and or XML) conversion could be quite a nice thing

gkellogg: if the datatype had an ID, would be used in output otherwise use base

jtandy: and in json, we'd ignore it / use base

gkellogg: seems a reasonable extension point

jenit: shall i make a proposal? separate issue? ok...

(… will write that out after the call)

jenit: that would allow a named xsd datatype to be used, carried through, validated etc

<jtandy> [example: "datatype": {"base": "boolean", "format": "#|-", "@id": "http://example.org/mydatatype" }

<JeniT> https://github.com/w3c/csvw/issues/534

jenit: also: issue #534 from Gregg

gkellogg: seems to have been shot down

…. doesn't change any processing

… moves responsibility for specifics of metadata into metadata doc rather than datamodel

… but late in the game.

… maybe we need a status 'deferring for v2' label [in github]?

(ivan … would need to do this)

(label vs milestone)

<JeniT> ivan, please could you add a “vNext” label to Github so that we can label issues that we want to defer with it?

(schema.org has 'dim and distant future, possible never' milestone: https://github.com/schemaorg/schemaorg/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22The+distant%2C+hazy+future+%28or+possibly+never%29%22 )

<gkellogg> And then set #534 to vNext

jenit: other open issues not flagged for discussion:

<ivan> I have created a "Deferred to Version 2" label to github

… waiting for I18n. Unions discussed. Changes - we know needs doing. Registration templ gone in. Data Cube 509:

https://github.com/w3c/csvw/issues/509

jtandy: done all needed doing. waited for a response, fine to close it.

+1 to close it

… could easily mark it as resolved. he's been emailed.

case insensitivity - close.

xsd - discussed

allowing metadata in csv files - …

gkellogg: we do talk about it, but don't say how

… just that it is a processor specific thing

[...]

gkellogg; we have made the ability to express arbitrary rdf from a csv rather general purpose

eg. you could have a csv that could be turned to json-ld to be a csvw metadata file

jtandy: net result from whatever arrangement needs to be an annotated table

see #534

gkellogg: someone could do this and be compatible

danbri: json-ld inside html via <script>?

gkellogg: "CSV" is fuzzy as needn't be actual CSV

tables … smiilar, considering html tables

jenit: afaik there is nothing in spec that stops you from saying an HTML file is a tabular data file, from which you can extract (via some uknown process) some json metadata AND an annotated table model

gkellogg: if metadata is script tag w/ json-ld vfersion of our metadata

and table uri can be resolved to a table fragment

moving on,

#528:

document requirement for conneg for retrieving the context document

gkellogg: why to do this?

… an actual processor needn't have to do this

json-ld tool chains if used will handle this

not sure why we'll need to do something here

jenti: i think the issue just articulaltes reader's surprise.. .add a note?

gkellogg: ok, will do

jenit marks as editor action

access control allow origin — ivan is doing this

or done

… specifically for this context file

gkellogg: some q of whether it negotiates over anything but the json-ld

<jtandy> +1

jenit: can close?

+1

<scribe> closed.

jenit: descr of line terminators. -> editor action.

… on the ns doc

gkellogg: I don't think we can close that one above. re accss control.

csvw vs csvw.jsonld

ah

gkellogg: sorry, it is done. Close!

<JeniT> https://github.com/w3c/csvw/issues/532

jenit: ok, closed.

#532 - editor action on gregg, update property definitions, line terminator, ...

jtandy: i took a look, don't consider it garbled. Name and then a title for that element.

not confusing, … but may look weird

jenit: description says […]

#534 - discussed.

… anything else needing progress e.g. use case doc?

gkellogg: also tests. I stalled out on generating a lot of new tests.

… probably another 100 tests, easily, if not more.

… a q of when to say "enough!"?

jenit: gkellogg, can you add issues like "add tests around section n" in github? to break up the work?

gkellogg: will do

jenit: that would be useful. Also usecase doc. Nothing back from Davide around reworking the requirements. Jeremy: can you take that on?

jtandy: struggling with bandwidth currently. Not a giant job to cross-ref but I would struggle to make time.

danbri; what exactly needs doing?

<jtandy> http://w3c.github.io/csvw/use-cases-and-requirements/#req

jtandy: 3.1 accepted requirements is blank. 3.2 candidate requirements. Consider 1st one: well formed csv check, …

… with most of these we have 1 liners. Felt to me as though now that we understand better what that requirement is as we've written the code, … can we flesh out meaning

jtandy: also a bunch that never made it out of candidate
... could try splitting it by the 4 sections

jenit: to split requirements out

… people then move them into either accepted, rejected, deferred

jtandy: lumpy distribution across sections

doc vs github?

jtandy: just do in the doc

jenit work in the doc directly.

jtandy: as a default position, all requirements listed as candidate should go into the Accepted list

if exception we should flag it in github for review.

[discussion of implementations]

looking at start of meeting before rrsagent, the following text was typed:

JeniT https://github.com/w3c/csvw/issues/524

jenit: 2 issues require teleconf discussion. irc://irc.w3.org:6667/#524 re xsd schema datatypes, … …which I have tried to get some clarity on. Needs more discussion on github.

jtandy: seems we have someone who finds it simple to use xml schema, and perhaps doesn't appreciate how difficult others find it. But I don't want to have to make an xsd parser in e.g. Javascript.

rragent, please draft minutes

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/viua/via/
No ScribeNick specified.  Guessing ScribeNick: danbri-user1
Inferring Scribes: danbri-user1

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: JeniT danbri gkellogg https ivan jenti jtandy
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 06 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/06-csvw-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report