Re: Moving personlization forward - wording suggestion

Hi Lisa,

I struggle to keep this many things in mind when on a call, but I will try.

A couple of things I don’t understand or will comment on:

> The first bullet can gives a loophole in some cases and can be more work then the second bullet in other cases - but it serves two purposes. Firstly it means there is no requirement to add more semantics.

AC: I don’t understand how that can be the case. In order for an on-page solution to work you have to go through the process of working out what to change (i.e. what the appropriate semantics are). Then, you also have to implement a mechanism for those things to change.

I see that the scope of the first bullet is tighter, but that is also a problem.

The current wording is unbalanced because the 1st and 2nd bullets are “OR”, but they are not equivalent.

If these two bullets use an “OR”, they should be equivalent methods of doing a similar thing, or they should be separated into two different SCs, perhaps one at A and a second at AA (or AA and AAA).

I don’t think that is a worthwhile approach though, I’d rather scope the meta-data aspect better.


> The last time this issue was discussed some members felt strongly that we can not expect people to add semantics reliably.

I think you will get more push-back from requiring an on-page solution, and in comparison pushing for a *well scoped* set of semantics would be easier and better.


> So if you cannot do it, you can copy and paste a script or have an alternative version.

If there is a simple script you can copy & paste, then it would apply across all (or most) sites, in which case it might as well be a user-agent script. However, I am very sceptical any such script would be of use to real people.

The ways in which sites are put together are too diverse, so any script that adds things to a site would need customisation per-site.

The only way it could work across sites is if there is a common semantic basis, i.e. the meta-data from coga-personalisation.

That’s why I think the 1st bullet is either pointless or unfeasible, depending on what it actually entails.


> Secondly, every platform will support it.

Sorry, support what? I know I’ve separated your comments out, but even reading the original I can’t tell what you mean by “it”.

If you mean that other technologies like PDF can support the addition of icons, I’m not sure how that is different from providing alternative versions of content?


> Thirdly, even though we have found other supporting techniques, it is easier to do the second bullet point using the coga -semantics.

Are there any other techniques that are specific to personalisation? I couldn’t see any in the issue text that were not based on coga-personalisation or already applicable to other SCs.

I don’t have a problem with having an SC that essentially means “use coga-personalisation”, if the scope of that spec were clearer.


> However people are uncomfortable depending on it. SO the first bullet point clarifies to everyone that there is no dependency on coga semantics to conform to the SC.

The problem is that without coga-personalisation, there is no agreed scope for either bullet. I.e. there is nothing to say which controls should have icons. That means there is no testability. You’d either have to specify them in the SC (a terrible idea) or have an external reference.


> But in a summary, the point here is to get something in here, and build it up more in the supplement.

I agree, I have the same goal in mind but I’m trying to steer towards an approach that has worked before in the WCAG/W3C context.

Starting with a core of the most useful meta-data which is the most straightforward to apply would be that first step.

Even with that approach, without some known external technology (user agent) to do something with the meta-data means it will be a struggle. (You didn’t answer that point.)


> In terms of the other issues. I see the definition of common elements listing some of the values of coga-action, coga-field  and coga-destination, so it should be very well defined what you need to include.

Indeed, but if the SC points to that spec for definition of what can be applied, it shouldn’t have the open ones like coga-context.

There was also the question of whether the author is responsible for what happens when things are added to the layout.

Cheers,

-Alastair