Re: javascript implementation update

It's HXL: http://hxlstandard.org/ and we have a use case around it here:

http://www.w3.org/TR/csvw-ucr/#UC-CollatingHumanitarianResponseInformation

Cheers,

Jeni
On 11 Mar 2015 21:11, "Gregg Kellogg" <gregg@greggkellogg.net> wrote:

> Hi Ed,
>
> > On Mar 11, 2015, at 1:12 PM, Ed Summers <ehs@pobox.com> wrote:
> >
> > Thanks for your email Jeni. I appreciate you all talking about this at
> the f2f.
> >
> >> On Mar 10, 2015, at 4:23 PM, Jeni Tennison <jeni@jenitennison.com>
> wrote:
> >>
> >> We’ve tried to simplify the merge algorithm quite a bit since the F2F.
> I think the only other option wrt merging would require us to limit the
> types of tabular data that could be processed (ie assume that the only
> embedded metadata is column titles) and leave unspecified the ability to
> override processing by the browser, both of which would be possible to do
> but are (from my perspective) a pretty high price.
> >
> > Is the merging metadata section of the Metadata Vocabularies for Tabular
> Data [1] the best place to look for the latest algorithm?
>
> Yes, that algorithm is pretty stable at this point. However, we just
> resolved issue #314 [3] which reduces the search for metadata to merge. It
> is now basically the embedded metadata along with the first metadata file
> found, or that started with. For the embedded metadata we've described,
> this amounts to merging columns and validating against any titles defined
> for those columns within metadata. Other standards may specify more
> complicated embedded metadata which could still invoke the recursive nature
> of the merge algorithm.
>
> > Does CSVW define any types of embedded metadata for a CSV other than
> headings/column titles? It seems reasonable to require this level of
> merging, but the merging metadata files seems to add a lot of complexity to
> me, which could impair adoption.
>
> It's been important for us to separate the way in which metadata is found
> from the process in which it is merged to allow for other standards such as
> XHL, which embeds additional semantics inside of CSV headers (sorry, no
> reference, Jeni mentioned it and may have one).
>
> > If someone wants to redefine the semantics of a CSV file is it too much
> to ask them publish their own CSVW metadata file that points at the
> original CSV? I suspect I’m not fully understanding this use case. Was
> there a specific use case [2] that will help me understand better?
>
> Agreed that this should be spelled out in the use cases. At this point,
> for the embedded metadata we've described, merging is important to validate
> the metadata against the actual data so that a transformation does not emit
> garbage when the columns don't match up. The UCR does describe validation
> and other relevant requirements:
>
> R-CsvValidation
> R-CanonicalMappingInLieuOfAnnotation
> R-CommentLines
>
> Gregg
>
> > //Ed
> >
> > [1] https://w3c.github.io/csvw/metadata/
> > [2] http://www.w3.org/TR/2014/WD-csvw-ucr-20140327/
> >
> >>
> >> Cheers,
> >>
> >> Jeni
> >> --
> >> Jeni Tennison
> >> http://www.jenitennison.com/
> >>
> >> On 10 March 2015 at 18:27:21, Ed Summers (ehs@pobox.com) wrote:
> >>> Just out of curiosity, has there ever been any hushed talk about
> removing metadata merging,
> >>> or not making it a MUST?
> >>>
> >>>> On Mar 10, 2015, at 11:59 AM, Jeni Tennison wrote:
> >>>>
> >>>> Hi Bill,
> >>>>
> >>>> That sounds great!
> >>>>
> >>>> Our goal is to get new drafts out by the end of the month, and we’d
> be hopeful that there
> >>> wouldn’t be many changes between then and Recommendation. The
> “deadline” for implementations
> >>> will be July I think, so there’s time to get everything working.
> >>>>
> >>>> The implementation needs to be conformant to the specs, which means
> they need to do everything
> >>> that’s listed as a MUST, and that includes merging metadata…
> >>>>
> >>>> Have you got any tests that you can contribute into the test suite?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Jeni
> >>>> --
> >>>> Jeni Tennison
> >>>> http://www.jenitennison.com/
> >>>
> >>
> >>
> >
>
>