Re: Proposal for personalization semantics as vocabulary

The point of my message was to ask for evidence on the questions you 
raise. If you have evidence, please provide it. Absent that, I don't 
think we should hold open a decision that slows us up or creates more 
complexity than we need. More specifically:


On 10/10/2017 1:36 PM, lisa.seeman wrote:
> Hi
>
> It is more then limiting to future work. Questions include:
>
>   * does it limit current work including things that are in the
>     specification and may even have people working on implementations?
>
I don't know, does it? In my message I said I think the answer is no. If 
you think the opposite, please describe specifically how. I tried to 
address all your concerns that I know about.
>
>   * does it make some things more complicated?
>
I don't know, does it? I think no, and explained why. If you think it 
does, please say how.
>
>   * can we do a mix, where some items are a vocabulary and some items
>     are not? (We would only use this option if it becomes useful.)
>
I think that would increase the complexity - and reduce the number of 
likely implementations and slow the timeline - even more than I was 
worried about before. Can you say what a mix would look like and what 
problems it would solve that we don't currently have solutions for?
>
>  Alough some things might seem more simple, other items  become more 
> complex, such as logs and some of the alternate version attributes. 
> This is even more removed from the path of simplifying log and step by 
> proposing to  make "log" and "step" roles values.
I need more details about these use cases. The only one I had heard from 
you is log, and I addressed what I knew about it in my message. If you 
have explicit use cases, we need to see them to discuss them.
>
> Some people may also find the aria implementation more complex as a 
> vocabulary.
Who, and in what way? Please draw those people into the discussion so 
they can explain the issue. I didn't cover this in my message, but in 
the call yesterday explained that I think the implementation is no 
harder as a vocabulary because we would provide mappings to ARIA, RDFa, 
and Microdata, and I said that because of that we could have 
interoperability of a greater number of approaches than just the one if 
it's structured as an ARIA module.
>
> i am not saying no but maybe we should gather data on the questions 
> above before we decide.
That was the reason I sent my message. I was expecting you to respond to 
the points I raised, and I tried to structure it in a way to make it 
easy to respond to them one by one.

I'm concerned that simply saying we need more data, but not providing 
the data or even verifying that it exists, will slow down the work too 
much. I'm not saying we need to make a decision today, I want to make 
sure any concerns are evaluated, but we need to move forward at some 
point reasonably soon. If you have concerns about that, we need specifics.

Michael
>
> All the best
>
> Lisa Seeman
>
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter 
> <https://twitter.com/SeemanLisa>
>
>
>
>
> ---- On Tue, 10 Oct 2017 19:50:07 +0300 *Michael 
> Cooper<cooper@w3.org>* wrote ----
>
>     >From yesterday's discussion
>     <https://www.w3.org/2017/10/09-personalization-minutes.html#item06>
>     of this proposal, I gathered that the restructuring overall was
>     received favorably, but concern was raised that expressing
>     personalization semantics as a name-value pair vocabulary would be
>     limiting to future work. Here are some thoughts to see if they
>     help draw out discussion.
>
>     First, the personalization semantics as currently proposed *is* a
>     set of name-value pairs, there are no features proposed that do
>     not use that model. So it seemed to me proposing it as a generic
>     name-value pair vocabulary was an obvious transformation.
>
>     I haven't seen a proposal for future work that would not work as
>     name-value pairs, so keeping the door open for an unknown complex
>     future at the cost of simplicity and achievability today doesn't
>     seem useful.
>
>     Lisa raised the example of logs, which use several properties
>     together - which is not on its own a problem for the name-value
>     pair vocabulary model. Lisa said that logs might put these
>     properties on different nested elements and require more taxonomic
>     structure. However, in the log usage examples
>     <https://www.w3.org/TR/personalization-semantics-1.0/#log-usage-examples>
>     I only see one example where the properties are used on nested
>     elements, and in that third example the nested <div>  doesn't do
>     anything that shows there must be a nested div, where it wouldn't
>     work by putting both properties on the parent div. So at the
>     moment I don't see convincing evidence that taxonomic nesting is
>     required for use of the personalization semantics.
>
>     A name-value pair taxonomy doesn't *prevent* authors from using
>     sets of related properties on nested elements, it simply doesn't
>     provide intrinsic *validation* that any structure rules have been
>     followed at authoring time. The current version of the semantics
>     also doesn't provide any such validation. I think such validation
>     is "nice-to-have" and not essential.
>
>     Allowing sets of related properties to be used together on
>     different elements inherently makes implementation more complex.
>     It means for properties where this might happen, implementations
>     have to check the entire subtree just in case other properties
>     were provided, often only to find nothing after all. Implementers
>     will complain about extra processing cycles, and I think simple
>     implementations will simply declare that kind of work out of
>     scope. I understood that a major implementation target, at least
>     initially, would be things like greasemonkey scripts or simple
>     browser add-ons, and I think requiring property nesting support
>     will rule most of those implementations out.
>
>     If taxonomic nesting is a critical part of personalization, or is
>     expected to be in the future, we should consider what technology
>     is the appropriate target to address that. It gets closer to
>     defining element types with their attribute and content models,
>     which should be done in host languages. I don't think maintainers
>     of languages like HTML or SVG will welcome yet another set of
>     add-on semantics, and I don't think we have determined that ARIA
>     wants to take that on either. So if we have use cases for that, we
>     might be better served coordinating with other groups rather than
>     making a more complicated and aspirational spec ourselves.
>
>     If in spite of all the above the group does conclude - and gets
>     support from its sponsoring ARIA WG in the conclusion - that
>     taxonomic nesting is a requirement, then we should structure
>     personalization semantics as a taxonomy rather than a vocabulary.
>     However, I see no evidence that that is on the table for 1.0, even
>     if it remains on the table for future versions. Therefore I think
>     we should still do 1.0 as a taxonomy, and do it differently in the
>     next version if needed - perhaps with renaming as a separate
>     technology to avoid confusion if that is critical. Alternately, we
>     could define the vocabulary, and a taxonomy of the vocabulary
>     terms, in separate places so we can have both a simple vocabulary
>     and a more involved taxonomy for more involved implementations.
>
>     A primary reason I've seen for us to work on personalization
>     semantics, though, is to get the concept of personalization "out
>     there" in a lightweight manner so we could get rapid in-the-wild
>     implementation to demonstrate usefulness. Defining a standardized
>     vocabulary will help with interoperability of work that might
>     otherwise happen in a fragemented manner, but it will still be
>     seen as a "bolt-on" technology. I was expecting that we would
>     later focus on building the concepts more directly into the web
>     platform once we have demonstrated achievability and usefulness.
>     Overcomplicating the current version in favor of a future version
>     we might not create doesn't help with this goal.
>
>     I tried to break my thoughts up into paragraphs so people can
>     respond to individual points. I'd like to see if there is
>     additional data informing why a vocabulary is insufficient at this
>     time, and if so clarify our requirements and scope. Otherwise I
>     think we should follow a simplest-is-best approach, particularly
>     for version 1.0.
>
>     Michael
>
>
>     On 09/10/2017 12:44 PM, Michael Cooper wrote:
>
>         I have put together a hasty proposal for how the
>         personalization semantics would look like as a vocabulary:
>
>         https://rawgit.com/w3c/personalization-semantics/vocabulary-proposal/semantics.html
>
>         You may need to refresh once or twice to get the script to
>         format the table of contents etc.
>
>         Basically what I've done is:
>
>           * Move all the properties to a section called "List of
>             properties
>             <https://rawgit.com/w3c/personalization-semantics/vocabulary-proposal/semantics.html#list-of-properties>";
>           * Remove the "coga-" prefix from property names;
>           * Renamed the section "Semantic Properties" to
>             "Personalization Use Cases", so it focuses on the issues
>             we want to address, and then at the end of each
>             sub-section points to the individual properties that
>             relate to those use cases - down the road we might even
>             see fit to move this section into a separate use cases
>             document;
>           * Added an appendix "Vocabulary Implementations
>             <https://rawgit.com/w3c/personalization-semantics/vocabulary-proposal/semantics.html#vocabulary-implementations>"
>             that describes how items in this vocabulary could be used
>             in RDFa, ARIA, and HTML Microdata (very hasty / sketchy
>             for now) - we could add more formats as they occur to us.
>
>         Most of the work on the spec would still happen in the List of
>         properties section, and nothing is really substantively
>         different. The value of this is that it more clearly indicates
>         how the properties can apply to different technologies,
>         separates the properties from their use case rationale, and
>         gets rid of those pesky coga- prefixes in their names.
>
>         Michael
>
>
>
>