Re: Comments regarding the Tools Module

Thanks Lisa, I figured as much.

I filed them as issues in github as well so that we don't 'forget' them.

JF


On Tue, Sep 18, 2018 at 4:27 AM, lisa.seeman <lisa.seeman@zoho.com> wrote:

> This is just going to a first working draft, so it is simple to revist....
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter
> <https://twitter.com/SeemanLisa>
>
>
>
> ---- On Mon, 17 Sep 2018 23:50:54 +0300 *John Foliot
> <john.foliot@deque.com <john.foliot@deque.com>>* wrote ----
>
> Greetings,
>
> As part of the research I did for the newly proposed notation scheme I
> floated on today's call, I had the opportunity to revisit the Tools
> Module page
> <https://w3c.github.io/personalization-semantics/tools/index.html>. I
> have two comments to offer:
>
> Re: *3.2.1 messageimportance*
> (see: https://github.com/w3c/personalization-semantics/issues/90)
>
> Would not "importance" be a higher level requirement than just for
> messages? For example, in a scenario where a page is being "simplified",
> wouldn't the author want to denote sections of the content that is
> "critical" (and so do not "simplify it" away)? Could we not just reduce
> this to a value of "importance" and let it cover more use-cases?
>
>
> Re: *3.2.4 messagetime*
> (see: https://github.com/w3c/personalization-semantics/issues/91)
>
> Currently this states:
>
> *Supported values:* 24 hour date time format. DD.MM.YEAR.HOUR.MM -
> DD.MM.YEAR.HOUR.MM where the second date is an optional exclusive expiry
> date.
>
> May I suggest that this pattern is actually something of an anti-pattern
> (or at least, is "non-standard"). Can I propose that instead we require the
> date format to follow
> ISO 8601 <https://en.wikipedia.org/wiki/ISO_8601> (Date and Time Standard)
> <https://en.wikipedia.org/wiki/ISO_8601> which takes the format:
>
> 2018-09-17T16:48:58Z
> (YYYY-MM-DDTHH:MM:SS + Z which denotes UTC)
>
> Additionally, the ISO notation allows the author to specify the time based
> on either UTC or with a UTC off-set (which is not addressed in the current
> draft)
>
> Neither or these comments/issues are barn-burners, but we should perhaps
> revisit?
>
> JF
>
>
>
>
>
> --
> *John Foliot* | Principal Accessibility Strategist
>
> Deque Systems - Accessibility for Good
>
> deque.com
>
>
>


-- 
*John Foliot* | Principal Accessibility Strategist

Deque Systems - Accessibility for Good

deque.com