Hi Charles, As this was a comment on a Last Call draft, I just wanted to close the loop on this so we can record it in the Disposition of Comments.
Are you ok with leaving localization of the <author> element until version 2 of the spec? Are you ok for the specification to progress down the REC track? Please let us know by the 27th of May; otherwise we will have to assume you are ok with that (which I'm hopeful you are:)). Kind regards, Marcos On Thu, May 5, 2011 at 12:02 PM, Marcos Caceres <marcosscace...@gmail.com> wrote: > > On Thursday, May 5, 2011 at 6:38 AM, Charles McCathieNevile wrote: >> On Wed, 04 May 2011 18:29:50 +0200, Marcos Caceres >> <marcosscace...@gmail.com> wrote: >> >> > > Hi, >> > > >> > > I just realised that I actually localise my own name... >> > > But I cannot do that in config.xml. Likewise, I would >> > > like to localise the href for me which would be possible if I could >> > > localise the author element but isn't at the moment. >> > >> > Yes, this was a mistake. >> >> If we were at REC I would suggest this go into an erratum... > > Although it seems like a small thing, it's a significant change to the > parsing model for this kind of element. And if we change it for author, we > should also change it for <icon> too. > >> >> > > I don't know if this is too late for the current version, in which case >> > > please log it as an issue for the future. >> > >> > I think it is too late for this version. We have runtimes now at 99% and >> > even 100% conformance and adding this would make most runtimes >> > non-conforming. I think its more important now to push this spec to REC >> > and address these kinds of cases in a future version of the spec. >> >> Do we have a test for this? I propose that we allow our run-time (and >> other implementations, such as the validation used by Opera stores) to >> localise author, and if that makes us non-conforming we're letting good be >> an enemy of better (and the argument that we have conformant run-times >> then looks weaker). If we don't have a test for it, then we know there is >> a requirement in our spec that isn't tested anyway. > > There are no tests that combine xml:lang and the author element - so I think > you are in the clear wrt conformance (this also means that spec is in the > clear to allow this feature to be added later). So, :D. There are tests to > make sure that only the first author element in document order encountered is > selected: > > http://dev.w3.org/2006/waf/widgets/test-suite/#user-agent/ta-LYLMhryBBT/tests > > So, adding the behavior you are proposing could keep Opera conforming for the > purpose of the test suite: when <author> elements with no xml:lang are > present in a config.xml, behave as the spec says today. Otherwise, behave as > if <author> was localizable via xml:lang. > >> >> In paticular, since we have at least one live product (addons.opera.com >> submission process) that validates against the existing schema, we have >> the choice of either supporting the spec or supporting best practice here. >> What would you prefer us to do? > If I could have one wish, I wish Opera would first claim 100% conformance by > fixing the empty <name> element bug. Then, after that, we create a new spec > that makes both <author> (and <icon>!) localizable via xml:lang. Existing > content will continue work with the introduction of this new behavior and can > even be kept backwards compatible with existing runtimes if a few simple > rules are followed during authoring. However, if you can get both implemented > in a timely manner, that's also a huge win for authors. > >> >> > > Changing it to allow localisation would mean a change to the schema - >> > > and at least to Opera's implementation. I haven't yet checked (I only >> > > realised I want to do this but it isn't allowed today) whether we have >> > > any preference for making that change now or later. >> > >> > I think we should definitely add this to any future versions of the >> > spec. In fact, authors could actually start using multiple localized >> > author elements today and have them work in the future. >> > >> > If it is ok with you, we will add this to a future version of the spec? >> >> Notwithstanding the above, given that if you do add localised versions the >> required behaviour is clear in v1 >> processing, I can live with that if the group decides to take that >> approach. >> >> Pity though. Turns out we're not infallible yet ;) > It's amazing the things one finds when people actually start using stuff we > specify :) > > > -- Marcos Caceres http://datadriven.com.au
