"QSA alternate keywords" as feature at risk?

[aisaac]

I'm putting in the open a response I've given in the poll for pushing Conneg to CR...

I have just realized there's a complete set of features (the "QSA alternate" stuff) that is based on a data model (here and more details) that I didn't get the time to look at, because my attention was drown to other issues since it was published this summer. In fact I've noticed it only when @nicholascar closed the corresponding issue w3c/dxwg#1031 . I should have spotted it in the list for the plenary, but there were just too many of these issues to look at, each week.

My worries about these is that:

• it relies on a representation of profiles that may or may not be aligned with PROF, thus possibly undermining the coming PROF publication (it won't be very relevant if the WG publishes two even slightly different modelings for profiles)
• I don't see the how the complexity of the solution will appeal to implementers: if I was someone with alternative QSAs for serving profiles, it would seem simpler to just add the standard QSAs rather than to create and serve a full description of how to discover my alternative QSAs.

Out of these two concerns, the first is the most important, with respect to dependencies and consistency across the WG products.
But the second could be quite important, as hindrances to implementation could be a cause for flagging a feature at risk, unless enough implementations can be shown (is it the case?). And having such a novel feature never be published in a Working Draft before it reaches CR sounds a bit dangerous. Nobody out of the WG was ever given the opportunity to see it, basically.

I think that if this was put as feature at risk (if just to accommodate for a better alignment with - or direct use of - PROF when PROF is ready) then I would vote 'yes' to CR.

[nicholascar]

it relies on a representation of profiles that may or may not be aligned with PROF

I wish we could make an alignment but I've been warned off that. Now, with more time for Conneg, we may be able to do so.

I don't see the how the complexity of the solution will appeal to implementers:

I'm about to be making a "QSA alternate keywords" implementation (as well as a "QSA Functional Profile" one) so I'll get back to you on this one!

Nobody out of the WG was ever given the opportunity to see it, basically.

Looks like we have more time for this now...