W3C home > Mailing lists > Public > public-apa@w3.org > May 2017

Re: Another way forward? (Just an idea for discussion)

From: David Wood <david.wood@ephox.com>
Date: Thu, 4 May 2017 11:46:03 +1000
Message-ID: <CABdBTrYZkpHEOHkmwsEY80tRzEmqKY_hiiZgmKZ=7C28SeYJfQ@mail.gmail.com>
To: EA Draffan <ead@ecs.soton.ac.uk>
Cc: Katie Haritos-Shea GMAIL <ryladog@gmail.com>, "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>, Avneesh Singh <avneesh.sg@gmail.com>, John Foliot <john.foliot@deque.com>, David MacDonald <david100@sympatico.ca>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>, public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>, WCAG <w3c-wai-gl@w3.org>, W3C WAI Accessible Platform Architectures <public-apa@w3.org>, "public-rqtf@w3.org" <public-rqtf@w3.org>, DPUB mailing list <public-digipub-ig@w3.org>
Hi all,

I have no problem with manifest files, but can't help wondering if a bit of
polymorphic confusion caused us to get here.

Web Publications Use Cases and Requirements [1] uses the term "manifest" in
two different ways:

- Section 1.1: "In this document, manifest refers to an abstract means to
contain information necessary to the proper management, rendering, and so
on, of a publication. This is opposed to metadata that contains information
on the content of the publication like author, publication date, and so on."

This seems to be a manifest file as understood by computer folk.

- Section 3.1: "Thus, the Web Publication is duplicated many times,
resulting in a huge number of copies. There remains a single source
manifestation, and therefore one canonical identifier for all of the items
spread across devices and buyers."

This seems to be a FRBR manifest [2] as understood by librarians.

So then you get confusion on how parse sentences like these:

- Section 3.1: "BigRetailer receives a Web Publication from
EsteemedPublisher that it intends to add to its catalogue. BigRetailer
wants to adds it own “teaser” via an alternative reading order. To achieve
that, BigRetailer provides its own version of the publication’s manifest,
that the user agent will use instead of the publisher’s manifest."

Does that mean a replacement of a manifest file, or a different FRBR
manifest? It could be either. Worse, computer scientists and librarians
will parse it differently, with both parties being certain that they
understood.

It is worth noting that Web Publications for the Open Web Platform: Vision
And Technical Challenges [3] says that a manifest should be interpreted in
the FRBR context:

- Section 1.1: "A Web Publication is not just a collection of links— the
act of publishing involves obtaining resources and organizing them into a
publication, which must be “manifested” (in the FRBR [frbr] sense) by
having the resources available on a Web server."

So, am I late to this particular party, or is this a legitimate
misunderstanding?

Regards,
Dave

[1] https://www.w3.org/TR/pwp-ucr/
[2] c.f. http://kcoyle.net/frbr/?page_id=50
[3] https://www.w3.org/TR/pwp/


On Thu, May 4, 2017 at 5:12 AM, EA Draffan <ead@ecs.soton.ac.uk> wrote:

> The idea of a linked but separate document  or block of metadata that acts
> in the same way as the ONIX accessibility guidelines for ePub really would
> help if it flagged up accessibility options or the ability to personalise
> services.  Search engines could also offer targeted sites that comply as
> they would find the data.  https://idpf.github.io/a11y-
> guidelines/content/meta/onix.html
>
>
>
> There may be a need to map the ontology to include other items, but I can
> see this as a way forward that could help some of our SCs supporting
> cognitive disabilities where automatic testing was not possible.
>
>
>
> Best wishes
>
> E.A.
>
>
>
> Mrs E.A. Draffan
>
> WAIS, ECS , University of Southampton
>
> Mobile +44 (0)7976 289103 <+44%207976%20289103>
>
> http://access.ecs.soton.ac.uk
> <https://www.outlook.soton.ac.uk/owa/redir.aspx?C=69b1RzNTDwem3wbm4pLRmuYfTLt16YjcghtEpZBsF5Sebx78I2DUCA..&URL=http%3a%2f%2faccess.ecs.soton.ac.uk%2f>
>
> UK AAATE rep http://www.aaate.net/
> <https://www.outlook.soton.ac.uk/owa/redir.aspx?C=WUwOCw_4FszLSzcUbkoFdDkad8-Q_GrRfPYUJ_ol5l2ebx78I2DUCA..&URL=http%3a%2f%2fwww.aaate.net%2f>
>
>
>
> *From:* Katie Haritos-Shea GMAIL [mailto:ryladog@gmail.com]
> *Sent:* 03 May 2017 19:51
> *To:* 'Siegman, Tzviya - Hoboken' <tsiegman@wiley.com>; 'Avneesh Singh' <
> avneesh.sg@gmail.com>; 'John Foliot' <john.foliot@deque.com>; 'David
> MacDonald' <david100@sympatico.ca>
>
> *Cc:* 'public-cognitive-a11y-tf' <public-cognitive-a11y-tf@w3.org>;
> 'public-low-vision-a11y-tf' <public-low-vision-a11y-tf@w3.org>; 'WCAG' <
> w3c-wai-gl@w3.org>; 'W3C WAI Accessible Platform Architectures' <
> public-apa@w3.org>; public-rqtf@w3.org; 'DPUB mailing list' <
> public-digipub-ig@w3.org>
> *Subject:* RE: Another way forward? (Just an idea for discussion)
>
>
>
> I also think this overtakes and/or includes the concerns and needs around
> the proposed Accessibility Metadata SC. So I am happy to let that SC lay
> low and combine these efforts into one.
>
>
>
> ​​​​​** katie **
>
>
>
> *Katie Haritos-Shea*
> *Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)*
>
>
>
> *Cell: 703-371-5545 <(703)%20371-5545> **|* *ryladog@gmail.com*
> <ryladog@gmail.com> *|* *Oakton, VA **|* *LinkedIn Profile*
> <http://www.linkedin.com/in/katieharitosshea/> *|* *Office: 703-371-5545
> <(703)%20371-5545> **|* *@ryladog* <https://twitter.com/Ryladog>
>
> NOTE: The content of this email should be construed to always be an
> expression of my own personal independent opinion, unless I identify that I
> am speaking on behalf of Knowbility, as their AC Rep at the W3C - and -
> that my personal email never expresses the opinion of my employer, Deque
> Systems.
>
>
>
> *From:* Siegman, Tzviya - Hoboken [mailto:tsiegman@wiley.com
> <tsiegman@wiley.com>]
> *Sent:* Wednesday, May 3, 2017 2:33 PM
> *To:* Avneesh Singh <avneesh.sg@gmail.com>; John Foliot <
> john.foliot@deque.com>; David MacDonald <david100@sympatico.ca>
> *Cc:* public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>;
> public-low-vision-a11y-tf <public-low-vision-a11y-tf@w3.org>; WCAG <
> w3c-wai-gl@w3.org>; W3C WAI Accessible Platform Architectures <
> public-apa@w3.org>; public-rqtf@w3.org; DPUB mailing list <
> public-digipub-ig@w3.org>
> *Subject:* RE: Another way forward? (Just an idea for discussion)
>
>
>
> If we can sync up with WebApps, so much the better.
>
>
>
> John and David, I would love to explore this further. I think we may
> discover that several of us are on the same page with our goals of
> personalization. If we are addressing rendering, we should also consider
> CSS implications. This is shaping up to be a fun project! Is this something
> you’d like to explore now or later on in the life of Silver?
>
>
>
> Tzviya
>
>
>
> *Tzviya Siegman*
>
> Information Standards Lead
>
> Wiley
>
> 201-748-6884 <(201)%20748-6884>
>
> tsiegman@wiley.com
>
>
>
> *From:* Avneesh Singh [mailto:avneesh.sg@gmail.com <avneesh.sg@gmail.com>]
>
> *Sent:* Wednesday, May 03, 2017 2:11 PM
> *To:* John Foliot; David MacDonald
> *Cc:* public-cognitive-a11y-tf; public-low-vision-a11y-tf; WCAG; W3C WAI
> Accessible Platform Architectures; public-rqtf@w3.org; DPUB mailing list
> *Subject:* Re: Another way forward? (Just an idea for discussion)
>
>
>
> In EPUB 3 based specs, manifest contains the metadata including
> “accessibility metadata” and list of resources.
>
> It is an essential file in EPUB 3 based standards.
>
>
>
> In W3C we yet do not know what shape will manifest file take, but if the
> common concept can be used in WCAG and publishing, it would be a good
> approach.
>
>
>
> With regards
>
> Avneesh
>
>
>
> *From:* John Foliot
>
> *Sent:* Wednesday, May 3, 2017 23:00
>
> *To:* David MacDonald
>
> *Cc:* public-cognitive-a11y-tf ; public-low-vision-a11y-tf ; WCAG ; W3C
> WAI Accessible Platform Architectures ; public-rqtf@w3.org ; DPUB mailing
> list
>
> *Subject:* Re: Another way forward? (Just an idea for discussion)
>
>
>
> ​Hi David,
>
>
>
> I think you may have missed the core of my idea... a manifest file is an
> additional "web resource" that could live at either the page or site-wide
> level, and it is a linked file/document that provides information about the
> content. It would not necessarily be rendered on screen (although it
> potentially could), but rather I envision it as an author-created resource
> that could then be a means of providing personalization information and
> resources.
>
>
>
> In the Web-Apps Manifest proposal <https://www.w3.org/TR/appmanifest/>
> (previously referenced by Alastair as well as myself)​, it states:
>
>
>
> This specification defines a JSON-based manifest file that provides
> developers with a *centralized place* to put metadata associated with a
> web application. This * metadata includes, but is not limited to*, the
> web application's name, links to icons, as well as the preferred URL to
> open when a user launches the web application.
>
>
>
> Meanwhile, DPUB have stated:
>
>
>
> *manifest* refers to an *abstract means* to contain information necessary
> to the proper management, *rendering*, and so on, of a publication. This
> is opposed to metadata that contains information on the content of the
> publication like author, publication date, and so on. The precise format of
> how such a manifest is stored is not considered in this document.
>
>
>
> As such, this has *nothing* to do with the definition of web page, nor for
> that matter does it suggest that the manifest file would be a web page (any
> more than a WebVTT caption file is a "web page").
>
>
> (Using the highlighted terms above, it would potentially be a
> *centralized* JSON file that had alternate *rendering* information
> provided - where alternate rendering = personalization)
>
>
>
>
>
> In terms of whether or not this would be part of WCAG 2.1 - likely not,
> but it *MAY* be something we should be looking at for Silver, as it strikes
> me as an excellent opportunity to address some of the current issues we are
> grappling with around some of the COGA and LV Use-Cases.
>
>
>
> For example, a manifest file could provide a list of possible (multiple)
> style sheets that could then be exposed via the user-agent for end-user
> choice. It could also be the resource that links a "common words list" to a
> site (complete with potential glossary definitions) - or conversely, a list
> of "uncommon words" and definitions that could be referenced or adapted to
> meet COGA needs.
>
>
>
> Those are just two quick ideas off the top of my head, but at the end of
> the day the manifest file would be the file that describes "things" about
> the web resource, including important 'meta' "things" related to
> accessibility and personalization.
>
>
>
> As Leonard Rosenthol noted, there is the potential for some collaboration
> here that we should be mindful of, and if the Web-Apps manifest (a product
> of the Web Apps
>
> ​ ​
>
> WG) is open to having their draft web-apps manifest *ALSO* be the home for
> meta-personalization data
>
> ​ to improve accessibility​
>
> then I see the potential of stronger and faster take-up throughout the
> wider development community
>
> ​, moving the ball forward sooner and more robustly, as we then piggy-back
> onto existing efforts, rather than try to create a whole new thing.​
>
>
>
> JF
>
>
>
> On Wed, May 3, 2017 at 11:09 AM, David MacDonald <david100@sympatico.ca>
> wrote:
>
> I think Manifest is a good term and a useful concept... I think the
> "manifest" part of it translates fairly accurately to part of our
> definition of a web page, which is defined as
>
>
>
> "... plus any other resources that are used in the rendering or intended
> to be rendered together with it by a user agent
> <https://www.w3.org/TR/WCAG20/#useragentdef>"
>
>
>
> Manifest is elegant and I like it, but I don't think it adds anything to
> our definition of web page... except that in a future version (silver???)
> we may want to drop the URI bit and go with Manifest file. Perhaps it could
> find its way into an SC???
>
>
>
> However, I don't think for 2.1 we want to swap out "web page" for
> "manifest file". I think it would be too jarring for a dot release. I'm
> glad to hear about it though and think we should keep it on our radar for
> future discussions.
>
>
>
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
>
> *            Including those with disabilities*
>
>
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
>
> On Wed, May 3, 2017 at 11:50 AM, John Foliot <john.foliot@deque.com>
> wrote:
>
> Greetings all,
>
>
>
> As part of an APA task I was assigned, I recently reviewed another W3C
> Working Draft ("Web Publications Use Cases and Requirements -
> https://www.w3.org/TR/pwp-ucr/) which introduces a proposed concept of a
> Manifest file, defined there as:
>
>
>
> "...an abstract means to contain information necessary to the proper
> management, rendering, and so on, of a publication. This is opposed to
> metadata that contains information on the content of the publication like
> author, publication date, and so on. The precise format of how such a
> manifest is stored is not considered in this document."
>
>
>
> I began to wonder aloud if using a similar mechanism (up to, and including
> piggy-backing on the Digital Publishing's IG concept of 'manifest' above)
> might not be a more efficient and economical way of capturing and conveying *personalization
> options* at a site-wide level (as opposed to the "page" or single-screen
> level). I could envision this addressing concerns from both the COGA and LV
> Task Forces in a fashion that scales efficiently for developers.
>
>
>
> While I don't have a clear vision of how all of this might be accomplished
> today, it strikes me as well that working in concert with the Digital
> Publishing Group on this piece of the larger puzzle could be quite fruitful.
>
>
>
> Please note that I am not at this time suggesting we abandon efforts
> produced to date, but I am suggesting that we may want to step back a bit
> and ingest the idea of a manifest file as part of our efforts, as clearly
> other groups within the W3C are using "manifests" (and/or are proposing to
> do so). See also: https://www.w3.org/TR/appmanifest/
>
>
>
> Thus, I open this for discussion only - but off the top I think there is
> some real merit in thinking about this more.
>
>
>
> JF
>
> --
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com
>
>
>
> Advancing the mission of digital accessibility and inclusion
>
>
>
>
>
>
>
> --
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com
>
>
>
> Advancing the mission of digital accessibility and inclusion
>
Received on Thursday, 4 May 2017 01:46:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:26 UTC