are we ready for the merge? from lisa.seeman on 2017-11-28 (public-personalization-tf@w3.org from November 2017)

From: lisa.seeman <lisa.seeman@zoho.com>
Date: Tue, 28 Nov 2017 20:27:57 +0200
To: "public-personalization-tf" <public-personalization-tf@w3.org>
Message-Id: <16003e0db2b.106a36ef3108166.9177775131158724370@zoho.com>

Hi folksRoy worked some more on the modules.
Please take a look, if there are no objections we could merge tomorrow.

You can see the whole document at : https://rawgit.com/w3c/personalization-semantics/explainer/explainer/explainer.html

You can see the individual modules at:

content: https://rawgit.com/w3c/personalization-semantics/explainer/explainer/content/content.html
help and support: https://rawgit.com/w3c/personalization-semantics/explainer/explainer/help/help.html
tools: https://rawgit.com/w3c/personalization-semantics/explainer/explainer/tools/tools.html

All the best

Lisa Seeman

LinkedIn, Twitter

On Nov 28, 2017, at 3:11 AM, Roy Ran &lt;ran@w3.org&gt; wrote:

Hi Lisa,
I have already changed and fixed those modules as your list, please find below URLs.
explainer: https://rawgit.com/w3c/personalization-semantics/explainer/explainer/explainer.html
content: https://rawgit.com/w3c/personalization-semantics/explainer/explainer/content/content.html
help and support: https://rawgit.com/w3c/personalization-semantics/explainer/explainer/help/help.html
tools: https://rawgit.com/w3c/personalization-semantics/explainer/explainer/tools/tools.html
Best,
Roy

在 2017/11/28 上午4:12, lisa.seeman 写道:

Hi Roy

Here is my proposed table of content
I left the implementations as an appendix, but it might need to be part of each module. Michael, do you think we can have one implementation section for all the modules?

TOC

Status of This Document
1. Introduction
1.1 Why We Need Personalization
1.2 Personalization Use Cases (general)
1.3 Structure of this document
2. Important Terms

3 Structure of Properties
3.1 Related Concepts
3.2 Value

4. Adaptable content
4.1 Use Cases
4.1.1 Simplification
4.1.2 Adding Context
4.1.2.1 General context
4.1.2.2 symbols
4.2 List of properties
4.2.1 action
4.2.2 destination
4.2.3 field
4.2.4 simplification
4.2.5 distraction
4.2.6 symbol

5. Help and support
5.1 Use Cases
5.1.2 Number free
5.1.3 Language type support
5.1.4 Non-literal text and images
5.1.5 More Help
5.1.5 Explain and feedback
5.1.6 Potential Features
5.2 List of properties

5.2.1 literal
5.2.2 numberfree
5.2.3 easylang
5.2.4 alternative
5.2.5 explain
5.2.6 feedback
5.2.7 moreinfo
5.2.8 extrahelp
5.2.9 helptype

6. Tools
6.1 Use Cases
6.1.1 logs
6.1.2 reminders
6.1.3 general tools
6.2 List of properties
6.2.1 All the log properties
6.2.1.1 Log usage examples
6.2.2 All the message properties
6.2.2.1 messageimportance
6.2.2.2 messagefrom
6.2.2.3 messagecontext
6.2.2.4 messagetime

A. Vocabulary Implementations
A.1 mapping values to different syntax
A.2 WAI-ARIA
A.2.1 Additional WAI-ARIA roles
A.3 HTML Microdata
A.4 RDFa
A.5 autocomplete

B. Acknowledgments
B.1 Participants active in the ARIA WG at the time of publication
B.2 Other ARIA contributors, commenters, and previously active participants
B.3 Enabling funders
C. References
C.1 Informative references
1. Introduction§

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Mon, 27 Nov 2017 18:40:29 +0200 Roy Ran&lt;ran@w3.org&gt; wrote ----

Hi Michael,
Actually, I have put the description value tables to the explainer.html, I will follow your advice and put them to the three modules in my daytime today, thank you for your advice.
Best,
Roy.

在 2017/11/27 下午10:21, Michael Cooper 写道:

Hi Roy - this is looking closer to what I was anticipating, bit still looks incomplete. The explainer file has 6 Respec errors to fix. The three modules seem to have only the examples for each of the properties, not the description value tables from each of the properties. Other more minor comments, but those are the things I'd like to address to support TF review. Michael

On 23/11/2017 5:01 AM, Roy Ran wrote:

Hi Lisa,
I will not delete coga-literal, coga-numberfree, coga-easylang and coga-alternative. Actually I set up four HTML documents for this branch[1].
1. explainer.html [2], this one includes the all description of properties according the list which you sent to me previous, but I extract the examples for each properties to three single HTML files (content.html [3], help.html [4] and tools.html [5]), and add a link to each example.
For the content.html, help.html and tools.html, I just put the example of properties in them, but for these three HTML files, if you want to contain other aspect, please let me know, I can change it.

2. content.html, this one includes examples for coga-action, coga-destination, coga-field, coga-simplification, coga-distraction and coga-symbol. each example has a separated fold for convenient maintenance.
3. help.html, this one includes examples for "help and support".
4. tools.html, this one includes examples for "tools".
Yesterday, I moved the original properties content to the explainer.html and moved the examples to content.html, help.html and tools.html, and now I am trying write some brief introduction for each specs and not finished yet.
If there is some unreasonable, please let me know, I could change it as soon, thank you.

[1] https://github.com/w3c/personalization-semantics/tree/explainer/explainer

[2] https://cdn.rawgit.com/w3c/personalization-semantics/explainer/explainer/explainer.html

[3] https://cdn.rawgit.com/w3c/personalization-semantics/explainer/explainer/content/content.html

[4] https://cdn.rawgit.com/w3c/personalization-semantics/explainer/explainer/help/help.html

[5] https://cdn.rawgit.com/w3c/personalization-semantics/explainer/explainer/tools/tools.html

Best regards,
Roy

在 2017/11/23 下午4:57, lisa.seeman 写道:

Hi Ron

Please do not delete coga-literal, coga-numberfree, coga-easylang and coga-alternative. There is redundancy but there is reasons for it which should be discussed before they are removed.

Please add them to the second module (help and support module). That way they get discussed together and do not hold up the first module

In each module, we want to keep an introduction a use case section and then a property section, implemetions sections etc, IE Most of the structure in the modul is the same as it is now.

Michael do you agree?

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Tue, 21 Nov 2017 18:49:56 +0200 Roy Ran&lt;ran@w3.org&gt; wrote ----

Hi Michael - thanks for your explanation, I will do that in my daytime today, sorry for my wrong understanding.
Best,

Roy

在 2017/11/21 下午11:10, Michael Cooper 写道:

On 21/11/2017 3:34 AM, Roy Ran wrote:

Hi Lisa,

Please kindly find the comments below.

在 2017/11/21 上午1:24, lisa.seeman 写道:

Hi Roy

I think we need to see what the proposal would look like.

For the proposal, in my personal opinion, coga-literal, coga-numberfree, coga-easylang and coga-alternative indeed exist amount of redundancy, so I would like to change the literal, numberfree and easylang to be the values of the coga-alternative as Joanie's suggestion, if so, I think I should remove coga-literal, coga-numberfree and coga-easylang and only remain the coga-alternative in the module, right?

To help review, we should not combine different types of proposals. The work you are doing should simply show how the spec would look if turned into explainer plus modules from its current form. Separately we can review the proposal to modify properties, and incorporate that later into the modularization proposal if we decide to support both.

DO you know how long it would take to convert it? If if it more then a few days it stops being relavent.

Sorry for I am not sure about what should be converted. Is that mean to convert the content of each example in personalization-sematics-1.0 to the new module(explainer module) ? if yes, maybe I can finish it in one day.

Right now I see only stub files in the documents at https://github.com/w3c/personalization-semantics/tree/explainer/explainer.

The three modules should be complete HTML files with Respec headers and all the necessary content to be W3C specs. They should also have introduction sections indicating how they relate to the explainer. Right now they have only a few headings without any of the content that should be related to those headings.

The explainer file should have the content from the introduction of the original, plus some information about the modules.

In the end, pretty much all the content from the original spec should be somewhere in one of these four files. So the proposal would show how the spec would look like when modularized.

Michael

Best regards,

Roy.

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Mon, 20 Nov 2017 09:40:57 +0200 Roy Ran&lt;ran@w3.org&gt; wrote ----

Hi Lisa,
I have already set up a module in GitHub, as Michael' s suggestion, I named the branch as "explainer".
The URL of this branch in GitHub is: https://github.com/w3c/personalization-semantics/tree/explainer/explainer
You could review the module website of the branch is: https://cdn.rawgit.com/w3c/personalization-semantics/explainer/explainer/explainer.html
If there is anything not reasonable for this module, please let me know, I will change it in time, thank you.
Best,
Roy.

在 2017/11/19 下午7:53, lisa.seeman 写道:

Hi Roy

Did you set up the example branch for modules? Can you do the brake up as I sugested in my email to the list?

IE:

1. Personalized Content
2. Personalized Help and support
3. Personalized Tools

"Content" includes things users need to understand what's on the screen
by ensuring it is familiar, and relevant:
* coga-action
* coga-destination
* coga-field
* coga-simplification
* coga-distraction
* coga-symbol

"Help and support" includes additional resources about content and to make it understandable :
coga-literal
* coga-numberfree
* coga-easylang
* coga-alternative
* coga-explain
* coga-feedback
* coga-moreinfo
* coga-extrahelp
* coga-helptype

"Tools" includes additional resources for keeping track of progress
within content:
* All the log properties
* All the message properties

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Sat, 18 Nov 2017 00:57:57 +0200 Joanmarie Diggs&lt;jdiggs@igalia.com&gt; wrote ----

Hi Lisa and Charles.

I have another proposal for your consideration. This one is regarding
content "alternatives", a need addressed by the following properties:
* coga-literal
* coga-numberfree
* coga-easylang
* coga-alternative

Right now, coga-alternative has an editor's note that says "This data
model may be too complex." I agree with that note. I also think
coga-alternative has a certain amount of redundancy with other existing
properties such as coga-easylang, coga-numberfree, and coga-literal. I
think this can be easily solved, and the solution is already suggested
in your spec example for coga-alternative. There you have this example:

&lt;div&gt;
&lt;span coga-alternative="easylang numberfree vocab1000" class="hidden"&gt;
most people prefer simple text
&lt;/span&gt;
... original, long text ...
&lt;/div&gt;

So you have a way authors can provide one alternative that addresses
multiple needs. That strikes me as a very good idea because it's easy
for authors. Plus the likelihood that one content alternative addresses
multiple need areas seems fairly high. That said, if an author wanted to
provide one alternative that is easylang and a different one that is
numberfree, they could presumably do:

&lt;div&gt;
&lt;span coga-alternative="easylang" class="hidden"&gt;
70% of people prefer simple text
&lt;/span&gt;
&lt;span coga-alternative="numberfree" class="hidden"&gt;
most people prefer simple text
&lt;/span&gt;
... original, long text ...
&lt;/div&gt;

In which case, why do we also need coga-numberfree and coga-easylang and
coga-literal? I think you could remove those dedicated properties and
make "numberfree", "easylang", and "literal" valid values of
coga-alternative (which you've already done).

The next task would be determining what other valid values are needed.
My recommendation would be to start with a small set which meets the
following requirements:

1. Describes the actual content used; not its appearance. "numberfree"
is good; I'd drop "whitespace" and "largefont."

2. Is independent of the content's medium. Could you use "realistic" or
"literal" (or a similar term) to describe both language which is not
symbolic as well as an image which is not symbolic?

3. Has a definition which most authors would not need to look up. Is my
message to you written in vocab500, vocab1000, or vocab2000? And if you
asked me to guess what p3 meant, it never would have occurred to me it
meant "disability centric illustrations that can disturb other people
and may be mid sentence."

Once you've got your list of possible values, consider making it another
schema.org extension, just like I'm suggesting you do with action,
destination, and field. Then valid values for coga-alternative become
the items in that extension. And when new values are added to the
extension, you don't need to update your spec with normative changes.

--joanie

--
Ruoxi Ran (Roy)
Web Accessibility Engineer
Personal Page：https://www.w3.org/People/Roy/

Received on Tuesday, 28 November 2017 18:28:28 UTC