W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > December 2017

RE: Conneg definition was: Re: Start of profiles analysis page - 2nd reply

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Thu, 14 Dec 2017 19:06:06 +0000
To: "mail@makxdekkers.com" <mail@makxdekkers.com>, "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>
Message-ID: <82f84457188b438ebdabed2267f94e43@dnb.de>
On Thursday, December 14, 2017 2:53 PM, mail@makxdekkers.com [mailto:mail@makxdekkers.com] wrote:

> The description of the guidance in the charter https://www.w3.org/2017/dxwg/charter

> is:
> Guidance on publishing application profiles of vocabularies.
> A definition of what is meant by an application profile and an explanation of one or
> more methods for publishing and sharing them.
> This does not limit the scope to only machine-readable expressions. Now, I don't think
> we should try to tell people how to write their documentation, but one of the things the
> WG could maybe say, is that it is good practice to publish a human-readable description
> of the profile alongside any machine-processable formats. We don't have to encourage
> nor discourage people publishing documentation as PDF -- people will do whatever
> works for their community.

Perhaps we could say that some kinds of documentation are normatively MUST requirements (e. g. an html page and -- depending on the kind of resources the profiles are supposed to describe -- some kind of machine-understandable schema document (XML schema, ShEx, JSON Schema, whatnot).

Regarding the organisation of those documents my view always was that there is a (abstract) URI for the profile that per content-negotiation gets us to the Right Resource for the Job (TM), be it PDF or plain html for humans and some kinds of machine-understandable stuff for machines. Html document can of course use <link> elements to point to further resources (perhaps we need a new relation) and the use of appropriate http Link-headers should be explicitly encouraged.

> On 12/14/17 1:57 AM, Peter.Winstanley@gov.scot wrote:
> > +1, esp in relation to PDF/A

I don't understand why PDF/A in this case would be different from any other PDF variant...



Received on Thursday, 14 December 2017 19:06:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:56 UTC