Re: Re: Proposal for personalization semantics as vocabulary

I added some comments inline, but my main issue was with logs.  Logs become much more complex. Logs needs to be a combination of role or tag name and stucture within the DOM. It can be done as a vocablary but it becomes out of the skill set of most web designers. 
With regard to implemention some folks at IBM had told me they were implementing it but I need to follow them up.



So my main question is - can we do a mix?


Also I am not sure about how the proposed attributes would work with ARIA. this seems like a coordination issue. 
We do not want to delay getting uptake of attributes in ARIA because we are making a vocabulary. 






---- On Tue, 10 Oct 2017 20:59:24 +0300 Michael Cooper <cooper@w3.org> wrote ---- 

  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.


Lisa:  logs becomes more complex. Logs needs to be a combination of role or tag name and stucture within the DOM. It can be done as a voablery but it becomes out of the skill set of most web designers. SOmeone at IBM had told me they were implementing it but I need to follow them up.
     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.
LS: as above
     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?


LS: Logs could be a mix. Idealy it should be an aria role and new attributes. 
   
 
  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, Twitter
 
 
 
 
  
 ---- On Tue, 10 Oct 2017 19:50:07 +0300 Michael Cooper<cooper@w3.org> wrote ---- 
 
    >From yesterday's discussion 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 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";
 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" 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