Re: Proposal for personalization semantics as vocabulary

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? 
does it make some things more complicated?
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.)



 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.


Some people may also find the aria implementation more complex as a vocabulary. 


i am not saying no but maybe we should gather data on the questions above before we decide.

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