/irc-logs / w3c / #webapps / 2009-05-13 / end

Options:

# Session Start: Wed May 13 00:00:00 2009
# Session Ident: #webapps
# [00:11] * Quits: arve (arve@84.202.133.45) (Quit: Ex-Chat)
# [00:41] * Joins: aroben (aroben@71.58.77.15)
# [01:00] * Quits: heycam (cam@203.217.72.53) (Quit: bye)
# [01:30] * Joins: heycam (cam@130.194.73.110)
# [02:07] * Joins: gavin__ (gavin@63.245.208.169)
# [02:07] * Quits: gavin_ (gavin@63.245.208.169) (Connection reset by peer)
# [02:13] * gavin__ is now known as gavin_
# [03:21] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
# [04:58] * Joins: shepazu (schepers@128.30.52.30)
# [05:59] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
# [08:38] * Quits: heycam (cam@130.194.73.110) (Quit: bye)
# [08:41] * Joins: tlr (tlr@128.30.52.30)
# [08:42] * Joins: heycam (cam@130.194.221.66)
# [08:56] * Joins: darobin (darobin@85.169.117.248)
# [09:17] * Quits: darobin (darobin@85.169.117.248) (Quit: darobin)
# [09:31] * Joins: darobin (darobin@85.169.117.248)
# [10:07] * Quits: heycam (cam@130.194.221.66) (Quit: bye)
# [10:37] * Joins: arve (arve@213.236.208.22)
# [10:41] * Quits: darobin (darobin@85.169.117.248) (Quit: darobin)
# [11:00] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
# [11:01] * Joins: arve (arve@213.236.208.22)
# [11:01] * Quits: arve (arve@213.236.208.22) (Client exited)
# [11:01] * Joins: heycam (cam@124.168.80.239)
# [11:01] * Joins: arve (arve@213.236.208.22)
# [11:14] <arve> Did someone ever define DOMTimeStamp?
# [11:14] <arve> oh, they did
# [11:24] * Joins: darobin (darobin@82.233.247.234)
# [11:57] * Joins: ArtB (d0309a43@128.30.52.43)
# [12:16] <ArtB> Marcos, yt? Arve says you need to do some anolis magic on http://dev.w3.org/cvsweb/2006/waf/widgets-api/Overview.src.html to get a "readable" version at "http://dev.w3.org/cvsweb/2006/waf/widgets-api/Overview.html". Would you please do that? That would be help me know which sections are incomplete (and hence should be added to tomorrow's agenda).
# [12:16] <Marcos> right
# [12:16] <Marcos> I will do that now
# [12:17] <ArtB> Thanks!
# [12:17] <Marcos> ok, uploading
# [12:18] <Marcos> ArtB: done
# [12:19] <Marcos> I'll try to add my issues today too
# [12:21] <ArtB> thanks
# [12:21] <ArtB> focus on P&C :)
# [12:22] <Marcos> aye aye!
# [12:29] * Quits: tlr (tlr@128.30.52.30) (Quit: leopard upgrade)
# [12:36] <Marcos> Hmmm... we never heard back from i18n
# [12:36] <Marcos> oh well
# [12:36] <Marcos> I guess we will flag them in the 2nd LC
# [12:44] <ArtB> Marcos, looks like they didn't discuss widgets during their May 6 call (http://www.w3.org/2009/05/06-core-minutes.html)
# [12:44] <Marcos> right "reply to 0023 to widgets saying that we intend to comment shortly and sorry for missing the 23rd"
# [12:45] <Marcos> Should I tell them not to worry?
# [12:45] <Marcos> and to hold off reading the 2nd LC doc
# [12:45] <Marcos> s/reading/reading to
# [12:46] <ArtB> I don't think it would make sense for them to review an ED knowing an LC will be published RSN
# [12:46] <Marcos> yeah, that's what I mean
# [12:47] <Marcos> sorry... I'm unarticulated today :)
# [12:47] <ArtB> we're on the same page on this one :)
# [12:47] <ArtB> Marcos, are you and JK working together on the L10n model?
# [12:48] <Marcos> I'm waiting for his input, I can't really do mine till I get his as they are co-dependent
# [12:48] <Marcos> well, mine section extends his
# [12:48] <Marcos> I need to read the email that Jere just sent in
# [12:49] <Marcos> Regardless, I've polished Step 7... almost done
# [12:49] <Marcos> Just need darobin to send me <access>
# [12:49] <Marcos> so REALLY close :D
# [12:50] <ArtB> I'll ping JK now
# [12:52] <ArtB> Arve, yt?
# [12:54] <ArtB> I think we want to remove "# be notified of events relating to the widget being updated," from the Abstract, right?
# [12:54] <ArtB> ... of A&E spec
# [12:55] <arve> ArtB: barely, but yes
# [12:55] <arve> (and that was two answers)
# [12:55] <Marcos> I'll do that
# [12:56] <Marcos> done
# [12:57] <Marcos> checked in
# [12:57] <ArtB> thankgs
# [12:58] <ArtB> Marcos, Arve - what is the purpose of the huge Red Block Isssue in section 5? http://dev.w3.org/2006/waf/widgets-api/#the-widget-interface
# [12:58] <Marcos> I need to fix that
# [12:58] <Marcos> it's a reminder
# [12:58] * Marcos goes to #wam to talk to jere
# [13:02] * Joins: JereK (c0647cda@128.30.52.43)
# [13:02] <Marcos> Let me recap
# [13:02] <Marcos> I need to adapt the following to Step 7 making use of whatever is produced out of Step 5 "Search the configuration document in document order. If, upon applying lookup, an element matches the user agent's locale, then the value of that matching element's xml:lang attribute becomes the widget's configuration document locale. If no match is made, then the use agent will only use unlocalized content from the configuration document."
# [13:03] <JereK> Wondering about 'document order'... that puts a burden on the creator of the config file.
# [13:04] <Marcos> darobin: hehe re: widgets
# [13:04] <Marcos> JereK: how so?
# [13:05] <JereK> Sorry, disregard that last remark. Brain overload...
# [13:05] <Marcos> Document order is important for elements that must not be duplicated. In which case the first one is the only one is used by the UA
# [13:05] <darobin> Marcos: you mean about Teledildonics?
# [13:06] <Marcos> Well, I wasn't going to use that word here, but yes
# [13:06] <darobin> Marcos: sorry, I'm on a call, I'll get back to you with <access> stuff right after
# [13:06] <darobin> :)
# [13:06] <JereK> There's a paragraph in Step 7 that talks about localized content, should that be there?
# [13:07] <JereK> The 3rd, starts with "If an author has placed...".
# [13:08] <Marcos> no, that should not be there. I have not worked on the localization parts as I was waiting to see what you were going to do with step 5 :)
# [13:09] <Marcos> I'm hoping I should just be able to "piggy back" whatever is defined in step 5.
# [13:09] <JereK> The thing is, the HTTP server model that Francois sketched is probably going to feature in Step 5, but dunno how much ATM.
# [13:09] <Marcos> that would be good.
# [13:10] <JereK> The para I mentioned needs to go somewhere in Section 8, I think.
# [13:11] <Marcos> Let me read your email. In the mean time, can you give me a high level overview of what you are thinking for Step 5 beyond what is already there?
# [13:11] <JereK> I suggest to rename Step 5 to "Determine the Widget Locale".
# [13:12] <JereK> The base folder only comes into play when the engine is doing the content negotiation.
# [13:12] <Marcos> right
# [13:13] <Marcos> I'm ok with that
# [13:13] <JereK> Then we need to make clear whether the widget locale is a list of language tags or a single one.
# [13:14] <JereK> And also how the subtags are applied in either case.
# [13:14] <Marcos> right
# [13:14] <Marcos> so, should we work through a scenario?
# [13:15] <Marcos> Make sure we are both on the same page
# [13:15] <JereK> Maybe the example is a bit too extensive, with both config document and resources. Tackle them separately?
# [13:15] <JereK> Yeah, let's do that.
# [13:16] <JereK> So do we still have separate 'folder locale' and 'config locale'?
# [13:16] <Marcos> Ok, so we agree that the UA locale is a list of one or more language tags?
# [13:16] <JereK> I think so, yes.
# [13:16] <Marcos> yes, we still have separate locales for config and folders
# [13:16] <JereK> I still don't get it, but that's my limitation...
# [13:16] <Marcos> so, starting with folders...
# [13:17] <Marcos> we will try to work out if we need two or not
# [13:17] <Marcos> two separate locales that is
# [13:17] <Marcos> so, assume the following widget:
# [13:17] <JereK> OK. So from the UA list we derive one or two widget related locales.
# [13:17] <Marcos> widget.wgt
# [13:17] <Marcos> locales/zh-Hans-CN/a.gif
# [13:17] <Marcos> locales/zh-Hans-CN/f.gif
# [13:17] <Marcos> locales/zh-Hans/a.gif
# [13:17] <Marcos> locales/zh-Hans/b.gif
# [13:17] <Marcos> locales/zh/a.gif
# [13:17] <Marcos> locales/zh/b.gif
# [13:18] <Marcos> locales/zh/c.gif
# [13:18] <Marcos> a.gif
# [13:18] <Marcos> b.gif
# [13:18] <Marcos> c.gif
# [13:18] <Marcos> d.gif
# [13:18] <Marcos> f.gif
# [13:18] <Marcos> g.gif
# [13:18] <Marcos> index.html
# [13:18] <Marcos> config.xml
# [13:18] <Marcos> hopefully that all got pasted in properly
# [13:18] <Marcos> is the last file "config.xml"?
# [13:18] <JereK> Yes. But let's keep the actual config file processing out for now.
# [13:19] <Marcos> right. As you said. So, lets assume "zh" as UA locale.
# [13:20] <JereK> OK, here the important cases are getting a.gif, c.gif or f.gif.
# [13:21] <Marcos> right
# [13:21] <JereK> Here the 'folder locale' would be simply zh, right? The only thing you can get from the UA locale.
# [13:22] <Marcos> right, so how do we derive that?
# [13:23] <JereK> Since the UA list has only one entry, that must be it. What if the UA locale list was "zh-Hans, zh"?
# [13:23] <Marcos> ok, that's probably a better place to start. Should we do normalization?
# [13:23] <Marcos> actually, no normalization needed there
# [13:23] <JereK> Define normalization :-)
# [13:24] <Marcos> never mind
# [13:24] <Marcos> :)
# [13:24] <JereK> y'know, I'm starting to think we could just use the UA list as is.
# [13:24] <Marcos> yes
# [13:25] <Marcos> so, run through the UA list and try to find matching directories.
# [13:25] <JereK> Right. To continue the walkthrough, say you want a.gif.
# [13:26] <JereK> Since the first one you try is locales/zh-Hans/a.gif, you're good.
# [13:26] <Marcos> The thing is that in step 5, we don't want any files. You just want a list of all the possible directories that match the UA language list
# [13:26] <JereK> Ahh... but do you need that list if you use the UA language list as is?
# [13:27] <Marcos> well, not the whole UA language list, just the directories that match one of the items in the list (searched from left to right, because the left most item is most preferred)
# [13:27] <JereK> Since like Francois sketched, locale is per resource. So if you don't find something for zh-Hans, you try zh.
# [13:27] <Marcos> ah right...
# [13:28] <Marcos> ah ok.. so you really don't have a "folder locale" at all
# [13:28] <JereK> In essence, the UA language list is your Accept-Language header equivalent.
# [13:28] <Marcos> makes sense
# [13:28] <JereK> Or do I simplify this too much even?
# [13:29] <Marcos> no, I think it's good... but it needs to be optimised... it can't be that we have to search the whole zip archive every time we want to find a fle
# [13:29] <Marcos> file
# [13:29] <JereK> That's what I was worried about in what I just wrote to the list...
# [13:30] <JereK> Though it's not really the whole ZIP, since you know where you need to start looking. It's max one complete branch of the tree per resource.
# [13:30] <Marcos> I wonder if we could do it "per directory" instead of per resource
# [13:31] <JereK> Not really, because there is no directory as such, just resources...
# [13:31] <Marcos> yes, that is true in HTTP land, but in Zip land you can get a distinction which you can leverage
# [13:32] <JereK> The 'locales' branch is an artifact of that. Sure those could have subdirs, but still it's like a specialization of anything that is in the root.
# [13:32] <JereK> Well, you could keep an index to the ZIP contents in memory and only access stuff when you know what to access.
# [13:34] <Marcos> I think it also helps that you know basically what you want and what you have so [au-lang-list] U [locale directories]
# [13:34] <Marcos> where U is "Lookup" ?
# [13:34] <Marcos> s/au/ua
# [13:34] <JereK> I though it was union :-) But maybe 'folder locale' is redundant after all. Everything is resolved at runtime, really.
# [13:35] <Marcos> right
# [13:35] <Marcos> hmmm
# [13:36] <JereK> So whenever you access a resource, you start looking for it based on the UA-language-list. If and when you exhaust that, you look in the root.
# [13:36] <Marcos> It does seem to simplify things
# [13:36] <JereK> Hopefully not too much.
# [13:37] <Marcos> It seems a bit "brutal"... but there is something nice about the simplicity of it
# [13:37] <JereK> Like Francois observed, there is the chance that you end up with partially localized widgets, but that's really the dev's problem.
# [13:38] <Marcos> ok, so I pass [ua-lang-list] to {blackbox + lookup} and out comes [resource] . I agree with Francois on that one
# [13:39] <Marcos> {blackbox + lookup + a list of all files}
# [13:39] <JereK> Me too. The analogy to HTTP is striking, but we don't need to make too much of that.
# [13:40] <JereK> If we have both zh-Hans and zh on the ua-language-list, do we need to do subtag searching then?
# [13:40] <JereK> Meaning if you don't find the resource for zh-Hans, do you drop Hans and look for zh, even though it is next on the list?
# [13:40] * ArtB votes for simplicity :)
# [13:41] <JereK> Or just rely on whatever the ua-language-list has?
# [13:41] * Marcos having a look if there is anything that can guide us in HTTP spec
# [13:42] <JereK> HTTP is still using RFC 3066, but it's not that much different from BCP47 in this sense, I guess.
# [13:42] <Marcos> That is what I was trying to say about "normalization" before
# [13:43] <JereK> Well, what does a typical web client do? Like, say, Firefox?
# [13:43] <Marcos> I think they only use 1 lang, but they let the server do that magic
# [13:43] <JereK> But they could have multiple tags, with q values and all...
# [13:43] <Marcos> right... I don't think anyone actually uses that
# [13:44] <Marcos> I would be EXTREMELY surprised if anyone actually processed that correctly
# [13:44] <JereK> Firefox: Preferences, Content, Languages. I at least have both en-us and en there as defaults, in that order. Would have to look at the headers.
# [13:45] <Marcos> I've got a debugging proxy
# [13:45] <Marcos> I'll see what happens when I contact google
# [13:45] <Marcos> one sec... firing it up
# [13:45] <JereK> xhaus.com/headers will do. Mine says: Accept-Language: en-us,en;q=0.5
# [13:45] <Marcos> ok
# [13:46] <Marcos> Ok, so they get sent
# [13:46] * Marcos has surprised look on face :)
# [13:46] <JereK> Sent, if not always observed by the server. I knew that, I wasn't surprised. :-)
# [13:47] <JereK> No normalization there, then.
# [13:47] <Marcos> ok, so do we take them as they are, or do we combine them and dump any redundant tags?
# [13:47] <JereK> I wouldn't go clomping on them, but use as is.
# [13:48] <JereK> Who knows which tags are redundant anyway?
# [13:48] <Marcos> yeah, clumping them together seems complicated.
# [13:49] <Marcos> ok, take them as is. The side effect is that you end up searching for the same thing twice
# [13:49] <Marcos> with Lookup, you are going to search for "en-us" then "en" and then "en" again
# [13:49] <JereK> Except if you rely on the list to contain all meaningful tags, so you don't need to process subtags...
# [13:49] <Marcos> I guess a smart implementation would keep track of what it's searched for already
# [13:50] <Marcos> so, implementation detail
# [13:50] <JereK> Is lookup the simplest thing in BCP47 for this? And how big is the hit? And yeah, for the same resource, the impl should know.
# [13:50] <Marcos> I think Lookup is the simplest... if you can call it that :)
# [13:51] * Joins: tlr (tlr@128.30.52.30)
# [13:51] <Marcos> at least you are never going to get folders with "*" so at least there is no need to worry about those
# [13:51] <Marcos> aside from that, it's pretty straight forward I think
# [13:52] <JereK> So back to the example, if you did look for a zh-Hans resource and didn't find it, you'd go searching for the zh one, but not move to the next tag on the UA list yet.
# [13:53] <Marcos> right
# [13:53] <Marcos> so, looking at step 5
# [13:53] <JereK> You'd exhaust the search, all the way to the root. So why would you ever need more than one tag from the UA list? That's what was nagging me.
# [13:53] <JereK> s/one tag/the first tag/
# [13:54] <Marcos> (me thinking that if we get this right, we don't need step 5!)
# [13:54] <Marcos> and step 5 becomes a "Rule for finding localized files"
# [13:55] <Marcos> or something like that
# [13:55] <JereK> That's plausible. Except the step is a runtime step.
# [13:55] <arve> hm, heycam around?
# [13:55] <Marcos> well, we use it in the configuration document (Step 7) to verify that files exist in the package
# [13:56] <JereK> You mean files referred to from the config file?
# [13:57] <Marcos> right
# [13:57] <Marcos> yes
# [13:57] <Marcos> like <icon src="someFile" />
# [13:58] <Marcos> what the UA goes searching for some file, it puts in the virtual Accept-header: [ua-lang-list]
# [13:58] <Marcos> and the UA does it's magic to find the file
# [13:58] <Marcos> I like that. It makes good sense
# [13:59] <Marcos> So, pretend step 5 is a Rule for Finding Localized Files.
# [14:00] <JereK> The concept of base folder goes away.
# [14:00] <Marcos> right! which is a great thing.
# [14:01] <heycam> hi arve
# [14:01] <Marcos> ... I hope :)
# [14:01] <JereK> Well it is, since at runtime you only need a language tag to look for a resource. Because locale is per resource, in this new model.
# [14:02] <Marcos> exactly.
# [14:02] <Marcos> so Lets modify Step 5 and make it into a rule
# [14:02] <Marcos> starting from 1. If the ua-language list is the string 'empty', or null, or the string 'i-default', or contains a string with a single '*', or a string that is a sequence of '*' characters (e.g. '*****'),
# [14:03] <Marcos> ^^ applies to the formulation of the ua-language-list
# [14:03] <Marcos> So!
# [14:03] <Marcos> "Within a user agent, the user agent's locale must be represented by one or more language tags, in lowercase form, and placed in the ua-language list. The first item must represent the user's preferred language range, followed by the next most preferred language range and so forth. Each language range must match the language-range production in [BCP47]. "
# [14:04] <JereK> That's OK. It could be used as is by the resource lookup.
# [14:06] <JereK> The base-folders production just became redundant.
# [14:06] <Marcos> I think we should drop that line (1). And it gets used when the UA generates the ua-language-list. That is, the UA must deal with 'empty', or null, or the string 'i-default', etc. appropriately.
# [14:07] <Marcos> so. from "2. For each range in the ua-language list:"
# [14:07] <JereK> So we're making an assumption of the validity of the ua-language-list?
# [14:08] <Marcos> I think the UA should "clean" the language list.
# [14:08] <arve> heycam: what's the status of "Implements" in WebIDL?
# [14:08] <JereK> If so, then the same holds for algorithm steps 2a, 2b and 2c.
# [14:09] <arve> I see it's a comment in the spec, and for internal stuff, I'll be assuming it gets in
# [14:09] <arve> I also think I'd like to see ImplementedOnAs
# [14:10] <arve> [ImplementedOnAs=Foo,bar]
# [14:10] <JereK> The stuff about things starting with 'locale/' could also go away.
# [14:10] <Marcos> right, JereK, so when the laguage list is derived from the OS, steps 2a, 2b and 2c are used
# [14:10] <arve> so that if I want to say that interface CatFeeder should be implenmented on House as "feeder", I could
# [14:11] <Marcos> I think we should keep locales/ because it makes it cleaner for authors and does give us an optimization point
# [14:11] <JereK> Marcos, if base-folders goes away and widget-locale is just ua-language-list, then what's it for?
# [14:12] <Marcos> I guess so when you do look for localized stuff, you only ever need to look in locales/ or at the root
# [14:12] <Marcos> and it was to protect authors so that the UA does not go searching in /en/ by accident
# [14:13] <JereK> Exactly! And you never put any 'locales/whatever' path prefixes in your URIs.
# [14:13] <Marcos> right
# [14:13] <Marcos> that is automatically resolved (unless you use an absolute path)
# [14:13] <JereK> Right. But does this apply to widget: URIs only then?
# [14:14] <JereK> And is a relative URI always considered a widget: URI?
# [14:14] <Marcos> yes. they both resolve to an absolute widget://
# [14:14] <JereK> Cool, then we're close to getting this nailed down.
# [14:15] <heycam> arve, yeah i haven't added the text for [Implements] yet
# [14:15] <heycam> but i think it makes sense to
# [14:15] <Marcos> Ok, so now I have
# [14:15] <heycam> don't always want to just inherit from that interface
# [14:16] <heycam> what'd [ImplementedOnAs] do?
# [14:16] <arve> it most definitely does, because I don't control the DOM3 specs, and can't add "ImplementedOn=Foo" to their document because I want to use it
# [14:16] <Marcos> When generating the ua-language list list, a user agent must validate all ranges. The ua-language list must be populated with only valid language subtags that are well-formed, as defined in [BCP47], which can help with canonicalization and matching obsolete and grandfathered subtags with a "preferred value". For each range in the ua-language list list:
# [14:16] <arve> heycam: the use-case here is for instance one of the Widget interface
# [14:16] <arve> I want to have some means of saying that the Widget interface is implemented on the Window object, as a property called "widget"
# [14:16] <Marcos> 1. If this range begins with the subtag '*' (e.g. "*-US"), then skip this range and, skipping all the steps below, repeat number 2 of this algorithm.
# [14:17] <heycam> arve, what in particular do you want to say [ImplementedOn] for but can't (since that'd edit the dom3 specs)?
# [14:17] <Marcos> ah crap
# [14:17] <heycam> arve, oh
# [14:17] <arve> heycam: in the specific case of Widget's we've worked around it by saying that it's implemented as a 'widget' property on whatever is the "Global" object
# [14:17] <heycam> you don't want to define, say, interface WindowWidget { readonly attribute Widget widget; } ?
# [14:18] <arve> heycam: that works only by convention
# [14:18] <heycam> in fact, [ImplementedOn=Window] interface WindowWidget { ... }
# [14:18] <Marcos> JereK: I'm trying to write how to clean up the language list
# [14:18] <arve> heycam: yes, but what is the attribute name used in that case?
# [14:18] <heycam> "widget"
# [14:18] <heycam> since that's the name of the attribute there
# [14:19] <JereK> Marcos, I'd say that algorithm steps 2d and 2e can go away too. Or not away, but somewhere else.
# [14:19] <heycam> [ImplementedOn=Window] interface WindowWidget { readonly attribute Widget widget; }
# [14:19] <JereK> Sorry, I meant steps 2a, 2b and 2c. Steps 2d and 2e can go.
# [14:19] <Marcos> Jerek, I've moved them.
# [14:19] <Marcos> Right.
# [14:19] <arve> heycam: yeah, seems to work
# [14:19] <Marcos> Lets move on from there
# [14:20] <JereK> Basically the whole algorithm is gone now. :-)
# [14:20] <heycam> arve, can you instantiate the problem that you need [ImplementedOn] for to the concrete problem? which interface do you want implemented on which objects?
# [14:20] <Marcos> ok, JereK, lets make sure... because we still need to define the negotiation.
# [14:20] <Marcos> I'm at "For each file entry in the widget package whose file name field begins with the string 'locales/"
# [14:21] <arve> heycam: no, on reviewing, I think you're right wrt to your solution
# [14:21] <heycam> ok
# [14:21] <Marcos> JereK:
# [14:21] <Marcos> right
# [14:21] <Marcos> the whole thing is garbage now :)
# [14:21] * heycam goes to bed
# [14:22] <arve> I think it's verbose, because I'd have to spec [ImplementedOn=Foo] interface WindowFoo { readonly attribute Bar bar; } instead of having a one-line pragma
# [14:22] <heycam> mm
# [14:22] <arve> but either works, because it's possible to autogenerate code from both
# [14:22] <JereK> Marcos, how about this: "Widgets refer to resources inside the widget package using widget:// URIs. These URIs are resolved at runtime using the ua-language-list." That's sketchy, but a start.
# [14:22] <Marcos> JereK: ok, that leaves us with no step 5.
# [14:23] <JereK> Marcos: right, what I just wrote would go somewhere else. Maybe say: "Step 5. There is no Step 5." :-)
# [14:24] <Marcos> ehehe... "take a break... grab a coffee... continue to step 6"
# [14:24] * tlr is now known as tlr-bbiab
# [14:24] <arve> Oh, break sounded like a good idea
# [14:24] <arve> heycam: thanks
# [14:25] <JereK> Marcos, continued: "The widget engine looks for a resource in a path of the form 'locales/' + language-tag. If not found, it successively removes the last subtag and tries again."
# [14:25] <JereK> "If the language tag is exhausted, but a match is not found, the engine looks for the resource at the root of the widget package."
# [14:26] <Marcos> JereK: going to take a quick break. BB in 3 mins
# [14:26] <JereK> Right, I'll do the same. BRB.
# [14:34] <Marcos> ok, back. I think this can go into the "processable file" definition
# [14:35] <JereK> What I don't get is, if we exhaust the tag, when do we ever move to the next one?
# [14:35] <Marcos> A processable file is a file that:
# [14:35] <Marcos> *exists within the said widget package,
# [14:35] <Marcos> *is a usable file entry,
# [14:35] <Marcos> *is of a media type supported by the user agent, determined applying either the rules for identifying the media type of an image or the rules for identifying the media type of a file. Which rule needs to be applied is given when the term is used.
# [14:35] <Marcos> to determine if the file exists
# [14:36] <Marcos> :
# [14:36] <Marcos> The widget engine looks for a resource in a path of the form 'locales/' + language-tag. If not found, it successively removes the last subtag and tries again.
# [14:36] <JereK> Note: need a definition of language-tag there.
# [14:37] <Marcos> language tag is defined else where and references BCP47
# [14:37] <JereK> No I mean in this context: that it's the currently processed element on the ua-language-list. So maybe language-tag isn't good to use there.
# [14:38] <Marcos> right
# [14:38] * JereK quickly gets a cup of coffee
# [14:41] <JereK> So, does the BCP47 lookup say that the tag must be exhausted? Or should we just move on to the next complete tag if something is not found?
# [14:42] <Marcos> I think we need to exhaust the tag
# [14:43] <Marcos> I guess that is the whole point of having the tags in the first place
# [14:43] <Marcos> otherwise, then name of languages would just have been used
# [14:43] <JereK> BCP47 says "When performing lookup, each language range in the language priority list is considered in turn, according to priority. ... The first matching tag found, according to the user's priority, is considered the closest match and is the item returned."
# [14:44] <Marcos> "the closest match" I guess meaning exhaust the tag
# [14:44] <JereK> And "For example, if the language range is "de-ch", a lookup operation can produce content with the tags "de" or "de-CH" but never content with the tag "de-CH-1996"."
# [14:44] <JereK> But lookup only returns a single result.
# [14:45] <JereK> Ahh, there it is: "In the lookup scheme, the language range is progressively truncated from the end until a matching language tag is located."
# [14:45] <Marcos> the above is what we want
# [14:45] <Marcos> right
# [14:45] <JereK> So WDYT: when will anything but the first tag in the list be considered?
# [14:46] <Marcos> only when you don't match something. Lets re-align quickly:
# [14:47] <Marcos> so UA-lang-list = {"de-ch, en-us"}
# [14:47] <Marcos> widget.wgt =
# [14:47] <Marcos> locales/de/file
# [14:47] <Marcos> locales/us/file
# [14:47] <Marcos> file
# [14:48] <Marcos> so, take the first language tag
# [14:48] <Marcos> try to match
# [14:48] <Marcos> nothing matches
# [14:48] <Marcos> remove the right most range
# [14:48] <Marcos> try again
# [14:48] <Marcos> locales/de matches
# [14:48] <JereK> Exactly.
# [14:49] <JereK> How about this: if you exhaust the tag, go to the root and still don't find the resource, you move on in the ua-language-list?
# [14:50] <JereK> And only if you've walked the whole UA list and still don't find the resource, it's finally an error.
# [14:50] <Marcos> exactly
# [14:50] * JereK finally gets it :-)
# [14:51] <Marcos> great stuff! makes everything real simple.
# [14:51] <JereK> Simple is good.
# [14:51] * Joins: tlr_ (tlr@194.154.216.66)
# [14:52] <Marcos> Artb will be proud :)
# [14:52] <Marcos> Ok, so lets spec it
# [14:52] <Marcos> == Rule for Finding Files Within a Widget Package ==
# [14:52] <JereK> On the fly? What is this, a Google job interview? :-)
# [14:53] <Marcos> lolz... is true... they made me do that when I interviewed there
# [14:53] <Marcos> the guy said to me "you are going to need a pencil... are you ready?"
# [14:54] <JereK> OK, I got as far as the root a while back. Need to add: "If the resource is not found, proceed to the next ua-language-list element and repeat."
# [14:54] * Quits: tlr_ (tlr@194.154.216.66) (Connection reset by peer)
# [14:55] * ArtB looks up; spec'in here is bettter than using a paper knapkin :)
# [14:55] <JereK> s/not found/not found in the root/
# [14:56] <Marcos> 1. for each lang-tag in the ua-lang-list:
# [14:56] <JereK> And: "If the ua-language-list is exhausted and the resource is not found, signal an error."
# [14:57] * Joins: tlr_ (tlr@194.154.216.66)
# [14:57] * Quits: tlr_ (tlr@194.154.216.66) (Connection reset by peer)
# [14:58] * Joins: tlr_ (tlr@194.154.216.66)
# [14:58] * Quits: tlr_ (tlr@194.154.216.66) (Client exited)
# [14:58] <Marcos> ok, step a. search the widget package a file entry that matches the concatenation of the string "locales/", the lang-tag, and the name of the file
# [14:58] <Marcos> b. if found, return that file entry
# [14:59] <Marcos> c. if not found, remove the right most range from the lang-tag
# [14:59] <Marcos> d. do "a" again
# [14:59] <Marcos> woops
# [15:00] <JereK> Guard for step d.: lang-tag could be already empty!
# [15:00] <Marcos> right
# [15:00] <Marcos> so d....
# [15:00] * Joins: tlr_ (tlr@194.154.216.66)
# [15:00] <Marcos> d. if lang tag is empty, search at the root of the widget package for the file
# [15:01] <Marcos> e. otherwise, do a again
# [15:01] <Marcos> woops, again
# [15:02] <Marcos> d. ... . If the file is not at the root of the widget package, the return an error.
# [15:02] <JereK> Maybe not yet... what about going to the next item in ua-language-list?
# [15:02] * Joins: Lachy (Lachlan@121.217.132.251)
# [15:02] <Marcos> oh yeah, good point :P
# [15:03] <JereK> If this were a for loop, you'd say continue at this point :-)
# [15:03] <Marcos> ok, lets try d again
# [15:04] * Quits: tlr_ (tlr@194.154.216.66) (Ping timeout)
# [15:05] <Marcos> d. if lang tag is empty, search at the root of the widget package for the file. If the file is not at the root of the widget package, do a again with the next lang tag in the ua-lang-list. If there are no more lang tags in the ua-lang-list, then return an error
# [15:06] <JereK> Yeah, I think that's how it works. Thanks for speccing that.
# [15:06] <Marcos> ok cool.
# [15:06] * tlr-bbiab is now known as tlr
# [15:07] <Marcos> hehe, my i18n document boils down to 5 lines to pseudo code :P
# [15:07] <Marcos> of*
# [15:07] <JereK> Echoes of Einstein: make it as simple etc.
# [15:08] <Marcos> ok, that solves it for files
# [15:08] <JereK> Can we apply this as is for config documents too?
# [15:08] <Marcos> That's what I was thinking
# [15:09] <Marcos> I wonder if it can be defined in terms of selectors
# [15:10] <JereK> Can you elaborate on selectors?
# [15:10] <Marcos> CSS selectors
# [15:10] <Marcos> I guess there is no need
# [15:10] <JereK> Right. In theory, yes. Impl support?
# [15:11] <Marcos> yeah, I was just thinking of defining it in terms of, but not actually having to have implementation support
# [15:11] <Marcos> so, for config....
# [15:11] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
# [15:11] <Marcos> hmmm
# [15:12] * Joins: ArtB (d0309a43@128.30.52.43)
# [15:12] <JereK> Once again, start from the ua-language-list.
# [15:12] <Marcos> 1. for each for each lang-tag in the ua-lang-list:
# [15:14] <Marcos> this one is a bit trickier, because do we "see what we have" or "search for what we need"?
# [15:14] <Marcos> the current approach is written to "see what we have"
# [15:14] <JereK> I'd say fInd the element whose xml:lang = lang-tag. If not found, chop off subtag and continue. So this more like search.
# [15:15] <Marcos> yeah, I guess that works
# [15:15] <JereK> And all of this is a block that's repeated for each element that could be localized.
# [15:15] <JereK> But like I wrote you, everything needs to be saved for later.
# [15:16] <Marcos> right
# [15:16] <Marcos> so you collect, then process?
# [15:16] <Marcos> you could collect all, then process OR collect and process as you go
# [15:16] <JereK> Does it make a difference either way?
# [15:16] <Marcos> I don't think so
# [15:17] <Marcos> does make the algorithm a bit more tricky...
# [15:17] <Marcos> lets use an example
# [15:17] <JereK> Collect, then process would be easier, I guess.
# [15:18] <Marcos> I think so too
# [15:18] <Marcos> <widget ..> <name xml-lang="en">a</name> <name xml-lang="en-us">a</name> </widget>
# [15:19] <Marcos> so, starting with ua-lang-list [en-us, en]
# [15:20] <Marcos> I certainly need to keep "found order"
# [15:20] <JereK> Why is that?
# [15:20] <Marcos> because en-us is preferred over en
# [15:21] <JereK> But the xml:lang values are unique, so it's just a hashtable with those values as keys.
# [15:22] <JereK> You collect them all anyway.
# [15:22] * Marcos not understanding
# [15:23] <JereK> You read all the name elements, put them in a hashtable with the xml:lang value as the key. So when you process the ua-lang-list, you pick stuff from there as needed.
# [15:23] <JereK> Therefore, document order and ua-lang-list order are orthogonal.
# [15:23] <JereK> That's what I meant earlier. I thought I was mistaken, but I must have been wrong. :-)
# [15:24] <darobin> so, friends
# [15:24] <darobin> regarding <access>
# [15:24] <darobin> we seem to have good discussion but no resolution
# [15:24] <Marcos> darobin: hold up
# [15:25] <Marcos> we are like 99% close to finishing i18n!
# [15:25] <darobin> is it dropped? does it stay in? do we keep it and put the security model in a separate spec?
# [15:25] <darobin> man, that's a high (five * 0.99) from me!
# [15:25] <Marcos> darobin: help us work through this quickly
# [15:25] <darobin> I'm all yours, what do you need?
# [15:25] <Marcos> darobin: we have:
# [15:25] <Marcos> <widget ..> <name xml-lang="en">a</name> <name xml-lang="en-us">a</name> </widget>
# [15:26] <tlr> xml-lang?!
# [15:26] <Marcos> the user agent locale is ["de, en"]
# [15:26] <darobin> s/xml-lang/xml:lang/ but yeah
# [15:26] <Marcos> woops
# [15:26] <Marcos> right
# [15:26] <tlr> that must be an xml6 idiom
# [15:26] <darobin> I told you you've been talking to avk too much
# [15:26] <Marcos> hehe
# [15:26] <Marcos> lolz
# [15:26] <Marcos> ok, so...
# [15:27] <Marcos> we take the first lang-tag (de).
# [15:27] <darobin> please don't tell me BCP47 doesn't define which one matches....
# [15:27] <Marcos> no, that's all good
# [15:27] <darobin> phew, go on
# [15:27] <Marcos> we are just trying to work out the process of gathering the right elements
# [15:27] <JereK> and I'm saying document order doesn't matter really
# [15:28] <Marcos> JereK: right
# [15:28] <darobin> I agree
# [15:28] <Marcos> so, UA attempt to match all elements whose xml":"lang match "de"
# [15:28] <darobin> it should only matter in the case where we have two elements with the same label
# [15:28] <Marcos> as there are none, nothing happens.,
# [15:28] <Marcos> so..
# [15:28] <Marcos> we move onto the next lang-tag
# [15:28] <Marcos> which is "en"
# [15:29] <Marcos> crap. I screwed up
# [15:29] <darobin> hahaha
# [15:29] <darobin> en would match en, not en-us — I think
# [15:29] <Marcos> make the next lang tag "en-us"
# [15:29] <darobin> that matches en-us
# [15:29] <Marcos> and matches en too
# [15:30] <darobin> yeah but it matches en-us more
# [15:30] <JereK> would match if the element for en-us wasn't found already
# [15:30] <Marcos> right, so that is the "order" problem
# [15:30] <darobin> if all you want is one result (ie the BCP47 "lookup") then you match the most specific
# [15:30] <Marcos> ah, ok
# [15:30] <Marcos> right
# [15:30] <JereK> it was found because it was more specific, not because it came first in the document
# [15:30] <darobin> and document order doesn't come into play
# [15:30] <Marcos> hang, JereK, I searched the whole document. I didn't search specifically for <name>
# [15:31] <JereK> still, it's per element
# [15:31] <Marcos> ok.
# [15:31] <darobin> if however your UA language tag had been "en", it would match "en" over "en-us" but not because of document order, simply because if the user asked for generic English, they shouldn't get some badly spelt jargon instead
# [15:32] <Marcos> right
# [15:32] <JereK> right, even if your UA list was "en,en-us"
# [15:32] <Marcos> en will never return en-us, etc
# [15:32] <darobin> right
# [15:32] <JereK> right
# [15:32] <JereK> two rights don't make a wrong
# [15:32] <darobin> wait, en should return en-us if there is only en-us in the document, no?
# [15:33] <JereK> I don't think so
# [15:33] <Marcos> no
# [15:33] <Marcos> it should not
# [15:33] <darobin> mmm, no you're right, that would lead to madness
# [15:33] <Marcos> it's the "sparta" rule
# [15:33] * JereK wonders what that is
# [15:34] * Marcos notes no one laughs at his 300 (the movie) reference
# [15:34] * darobin changes topic to 'under sparta rule'
# [15:34] * darobin laughed
# [15:34] * JereK thought of Animal House
# [15:34] * darobin throws Marcos into a bottomless pit
# [15:35] <Marcos> ok, so I've searched for *[xml:lang=en-us]
# [15:35] <Marcos> I get back a nodelist
# [15:35] <darobin> anyway, so to return to the subject, what about <widget ...> <name xml:lang="en">a</name> <name xml:lang="en">b</name> </widget>
# [15:35] <JereK> can't happen because xml:lang values are unique; how to enforce it, well...
# [15:36] <darobin> JereK: it can happen, I just made it happen :)
# [15:36] <JereK> that's document order at play, then
# [15:36] <darobin> exactly
# [15:36] <darobin> we just need to say first or last in document order
# [15:36] <Marcos> right, the spec says you ignore the second
# [15:36] <darobin> right
# [15:36] <darobin> all good
# [15:36] <darobin> does this close the remaining 1%?
# [15:37] <JereK> so in case you have more than one instance of the same elem with the same xml:lang value, you ignore all but the first
# [15:37] <darobin> yup
# [15:37] <Marcos> Ok, I've searched for *[xml:lang=en-us] and I have a NodeList. I now search for *[xml:lang=en] and get a second node list,
# [15:37] <Marcos> and I search for * but not with [xml:lang] (unlocalized)
# [15:38] <Marcos> so I have n NodeLists + 1
# [15:38] <Marcos> the first is the most preferred, the last is the least preferred
# [15:39] <Marcos> so I start trolling
# [15:39] * darobin notes that those selectors wouldn't exactly look like that, but gets the idea
# [15:39] <Marcos> I know, but I could not be bothered looking them up
# [15:39] <Marcos> anyway, you get the idea, so all is good
# [15:39] <Marcos> is the above a good way of doing things?
# [15:40] <Marcos> for each nodelist in the collected nodelists:
# [15:40] <Marcos> if the element is <name> then use it, and mark "name" as used.
# [15:40] <darobin> implementation-wise I wouldn't do it that way, and I don't think it should be specified based on selectors and DOM manipulation because then you have to actually get it right :) — but the idea is sound
# [15:41] <JereK> present though it may be)
# [15:41] <JereK> damn, this Web IRC client clears the line on a parenthesis, sorry
# [15:41] <Marcos> I'm just trying to implement in my head.
# [15:41] <darobin> heh
# [15:41] <JereK> I was saying that I would do it per element, as all of them don't have a meaningful xml:lang, present though it may be
# [15:41] <Marcos> NO ONE PUT IN ANY INFINITE LOOPS OR I WILL CRASH!
# [15:42] * JereK makes a mental note not to use parentheses
# [15:43] <Marcos> I guess it could be done per element
# [15:43] <JereK> so for each localizable element you have a dictionary where keys are xml:lang values
# [15:43] <darobin> Marcos: so, plugging my keyboard into your head
# [15:43] <darobin> say you want a name
# [15:43] <darobin> first, get /w:widget/w:name
# [15:43] * Marcos dares darobin to do this with xpath
# [15:44] <darobin> then for each UA lang, search for a w:name that matches, and return that when done
# [15:44] <darobin> rince, etc. repeat with next element
# [15:44] <Marcos> right
# [15:44] <darobin> doing what with XPath? selecting elements? that's.... trivial :)
# [15:44] <Marcos> I guess the other way, you don't need to run through ever possible element. Just the ones you have gathered
# [15:45] <darobin> that's really an implementation detail
# [15:45] <JereK> you only need to do it for name, icon, and what have you
# [15:45] <Marcos> right, but it's also a "specification detail" because it depends on how it is written
# [15:46] <Marcos> yes, only for the localizable elements
# [15:46] <Marcos> Ok, so lets gather what we have thus far then
# [15:46] <darobin> if two X elements have the same language tag, discard them all except for the first one; in the resulting list pick the one that matches the UA language list according to the BCP47 lookup algorithm
# [15:46] <darobin> there, done
# [15:46] <JereK> so when you've saved those elements in the dict, start going through the ua-lang-list like we defined for resources, and look for elements with those keys
# [15:47] <Marcos> right
# [15:47] <darobin> replace X with name, icon, description....
# [15:49] <darobin> Marcos: do you have notes on the string to zip rel path thing?
# [15:49] <Marcos> no
# [15:49] <darobin> ok, from scratch it is then!
# [15:50] * Marcos knocks on the hollow thing on top of his shoulders "It's all up here, baby"
# [15:50] <darobin> heh, well if you braindump on me I'll turn it into proper prose
# [15:50] <Marcos> JereK: I think we are good to go
# [15:50] <Marcos> I'll spec all this up
# [15:50] <darobin> I'm worried about <access> though, not sure whether we want to nuke it or if I should finish those changes
# [15:50] <JereK> Marcos: glad to hear that
# [15:50] <Marcos> darobin: initiating braindump
# [15:51] * Marcos prepares darobin, some scary shit from my childhood may leak out!
# [15:51] <JereK> I'm happy to review, although I was supposed to write parts, but I made them go away instead. Wow.
# [15:51] <Marcos> JereK: thanks for your time and help!
# [15:52] <JereK> Marcos: anytime. Got to go now, actually, anyway. TTYL.
# [15:52] <Marcos> cya!
# [15:52] <Marcos> darobin: ...so it begins...
# [15:52] * Parts: JereK (c0647cda@128.30.52.43)
# [15:52] <Marcos> so, you have a zip relative path.. it always looks like "path/to/file"
# [15:53] <Marcos> it should never contain a "/" at the front
# [15:53] <Marcos> if it does, then it's evil and something must be done.
# [15:53] <darobin> yeah, sure
# [15:53] <Marcos> darobin: that could mean, ignore the file entry
# [15:53] <Marcos> or drop the "/"
# [15:53] <darobin> I think it should mean ignore the file entry
# [15:54] <darobin> because we might want / later
# [15:54] <Marcos> the "/" is implied
# [15:54] <Marcos> zip relative paths are composed of any characters, but the spec puts a restriction on them. However, the spec does not define error handling. I think it just saysi
# [15:55] <Marcos> woops
# [15:55] <Marcos> it just says "die" if you find an invalid path
# [15:55] <darobin> I was wondering if we need to talk about encodings — though I think not since XML should just give us a string
# [15:56] <Marcos> darobin: see "Rules for Verifying a File Entry"
# [15:56] <darobin> same thing I think, characters not allowed should lead to the entry being ignored
# [15:56] <Marcos> darobin: the encoding comes in any flavor! HOWEVER, we pretend that it only comes in 2
# [15:56] <Marcos> CP-47 or UTF-8
# [15:56] <darobin> ah, but you're talking about converting a zip-rel-path to a string
# [15:57] <Marcos> as indicated by general purpose bit 11 of the local file header of a file entry
# [15:57] <darobin> I'm talking about the reverse
# [15:57] <darobin> yeah yeah, that I know
# [15:57] <Marcos> oh...
# [15:57] <Marcos> ok
# [15:57] <Marcos> sorry
# [15:57] <darobin> heh
# [15:57] <darobin> didn't we agree that zip-rel-path2string wasn't needed? maybe I wrote it down wrong
# [15:57] <Marcos> ok, a string to zip file entry is one that conforms to a zip relative path
# [15:58] <Marcos> ok... lets use an example
# [15:58] <darobin> right, that's what I thought, hence my puzzlement at the need for a section defining the conversion :)
# [15:58] <Marcos> <content src="f/u/nººb.wgt"
# [15:59] <darobin> make that content src="f/u/nººb.html"/>
# [15:59] <darobin> gah
# [15:59] <darobin> make that <content src="f/u/nººb.html"/>
# [15:59] <Marcos> hehe, use SGML, you bum :)
# [15:59] <darobin> I'm too young for SGML
# [16:00] <Marcos> hhehe. Ok, we will use your so called "XML"
# [16:00] <Marcos> right, so what is the value of src?
# [16:00] <Marcos> is it a)
# [16:00] <Marcos> a string?
# [16:00] <Marcos> b. a zip relative path?
# [16:00] <Marcos> c. a URI reference ?
# [16:00] <darobin> I think we agreed that it's not (c)
# [16:01] <darobin> conversion to URI references is a matter for another specification — this only points to content
# [16:01] <Marcos> right.
# [16:01] <darobin> but wait! now the L10N issue comes into play — we need it to be a URI ref so that it can point to different files depending on locale
# [16:01] <Marcos> right
# [16:01] <Marcos> kinda
# [16:02] <Marcos> ok
# [16:02] <darobin> is it okay if I just put "kinda" into the spec?
# [16:02] <Marcos> ok, wait!!!
# [16:02] <Marcos> Jere and I worked out the following algorithm for finding files:
# [16:03] <Marcos> So, pretend the widget engine does i10n like a HTTP server
# [16:03] <Marcos> 1. for each lang-tag in the ua-lang-list:
# [16:03] <Marcos> a. search the widget package a file entry that matches the concatenation of the string "locales/", the lang-tag, and the name of the file.
# [16:03] <Marcos> b. if found, return that file entry
# [16:03] <Marcos> d. if lang tag is empty, search at the root of the widget package for the file. If the file is not at the root of the widget package, do a again with the next lang tag in the ua-lang-list. If there are no more lang tags in the ua-lang-list, then return an error
# [16:03] <Marcos> e. otherwise, do a again.
# [16:04] <darobin> shouldn't it apply BCP47 lookup in step (a) so that en-us matches en?
# [16:04] <Marcos> so, there is no notion of "base folder" or any of that shit
# [16:04] <darobin> that is lovely
# [16:04] <darobin> so basically what that algo needs as input is a damn string
# [16:04] <Marcos> no, bpc47 is done when we generate the ua-lang-list
# [16:04] <Marcos> right
# [16:04] <darobin> ah, so if ua-lang-list contains en-us you append en after it?
# [16:05] <Marcos> yeah... and all the shit is all cleaned up, so you don't get any "en-*-us" nonesense
# [16:05] <darobin> ie, [de, en-us, fr] —> [de, en-us, en, fr]
# [16:05] <darobin> wonderful
# [16:05] <Marcos> right
# [16:05] <darobin> smart
# [16:05] <Marcos> that's what they pay me for :P
# [16:05] <darobin> so, to return to our sheep as say in French
# [16:06] <darobin> I meant that for Jere, but nevermind
# [16:06] * darobin ducks
# [16:06] <Marcos> hehe
# [16:06] <Marcos> ok, so f/u/nººb.wgt
# [16:06] <darobin> so the steps for converting a string to a ZRP is 1. let zrp be the value of @src
# [16:07] <darobin> and that's it :)
# [16:07] <Marcos> right, now, zip-rel-path to URI
# [16:07] <Marcos> wait
# [16:08] <Marcos> um..
# [16:08] <Marcos> brain is throwing unknown error
# [16:08] <darobin> I think you now see what I'm struggling with :)
# [16:09] <darobin> it seems that the "Rules for converting a string to a zip relative path" is actually useless, but something tells me it needs to be done
# [16:09] <Marcos> yeah
# [16:09] <Marcos> ...but why
# [16:09] <Marcos> what are we trying to solve?
# [16:11] <Marcos> ok, so, string to zip rel path
# [16:11] <Marcos> take the string, which is UTF8
# [16:11] <Marcos> ok, here we go. The zip contains both UTF8 and CP437 file names
# [16:12] <Marcos> now you are fracked.
# [16:12] <Marcos> better example
# [16:12] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
# [16:12] <Marcos> <content src="mañana.html"/>
# [16:13] <Marcos> ok, so
# [16:14] <Marcos> you still with me?
# [16:14] <Marcos> ñ in CP437 =
# [16:14] <Marcos> F1
# [16:14] <Marcos> ñ in UTF-8 =
# [16:15] <darobin> yes I'm here
# [16:15] <darobin> I see what you mean, but I think that's moot
# [16:16] <darobin> the encoding of ZRPs is known, so they can readily be converted into strings
# [16:16] <darobin> then strings can be compared together — you don't need to convert your string into whatever encoding the Zip used and use that to look things up in its table
# [16:16] <Marcos> no, how do I find mañana.html?
# [16:16] <darobin> the zip file is opened
# [16:17] <darobin> the encoding of its paths is known
# [16:17] <Marcos> so what, I have mañana.html (CP47) and mañana.html (UTF8)
# [16:17] <Marcos> right
# [16:17] <darobin> you say you can have two files called mañana.html in the same zip?
# [16:17] <Marcos> sure, because of i18n
# [16:18] <darobin> no, I mean with the same *zip path*
# [16:18] <Marcos> theoretically you could, because the bytes don't match
# [16:18] <Marcos> mañana.html (cp47) is not the same as mañana.html UTF8
# [16:18] <darobin> isn't the path encoding for the entire archive rather than for each entry?
# [16:18] <Marcos> no, it's per file entry!!!
# [16:18] <Marcos> AHHHHHH!!!!
# [16:18] <darobin> ah, well, that's easy we can handle that
# [16:19] * Marcos likes darobin nonchalant attitude
# [16:19] <darobin> so, for each entry you decode it according to its encoding
# [16:19] * Joins: aroben (aroben@71.58.77.15)
# [16:19] <darobin> if you already have that entry in your table, discard it
# [16:19] <darobin> there, done
# [16:19] <darobin> easy
# [16:20] <Marcos> right, so this assumes a table
# [16:20] <darobin> you create one :)
# [16:20] <Marcos> ok, but, I wanted mañana.html (cp47), but the string from the UTF-8 config.xml is in UTF-8
# [16:21] <Marcos> does that matter?
# [16:21] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
# [16:21] <Marcos> you see what I'm getting at? you need to convert your strings, no?
# [16:21] <darobin> the original encoding of the strings doesn't matter — you compare internal representations
# [16:22] <Marcos> I think it does matter. It needs to be made explicit because this is the biggest interop problem in zip.
# [16:23] <darobin> all that needs to be made explicit is what you do if you have two entries in a zip archive that resolve to the same name
# [16:24] <Marcos> no, forget that. Just take the simple case I presented. I have /mañana.html (CP437) and in the config I have mañana.html (UTF8)
# [16:24] <darobin> I would very much like to meet the morons who made this possible
# [16:24] <darobin> the encoding DOES. NOT. MATTER.
# [16:24] <darobin> say your internal representation for strings is UTF-16
# [16:25] <darobin> you read the zip, build an internal table by converting CP437 to utf16
# [16:25] <Marcos> yes, then you are cool
# [16:25] <darobin> you read the config.xml, build and internal representation by converting utf8 to utf16
# [16:25] <darobin> now you can compare the two
# [16:25] <Marcos> right, that is what needs to be made clear in the spec
# [16:25] <darobin> so long as we say in what encodings things are, we don't need to tell developers that they should compare strings
# [16:26] <Marcos> right, but all implementations I've tested on don't do what you said
# [16:26] <darobin> you want to put "strings should be compared based on character values, not on the byte values of their original encodings"?
# [16:26] <darobin> implementations of what? zip?
# [16:26] <Marcos> no, I want to do what you said:
# [16:26] * Joins: tlr (tlr@128.30.52.30)
# [16:27] <Marcos> implementations of widgets engines and of zip
# [16:27] <Marcos> http://datadriven.com.au/2008/12/08/zip-files-and-encoding-i-hate-you/
# [16:27] <darobin> gee, you'll use any excuse to get some extra hits on your blog
# [16:27] <darobin> :-D
# [16:27] <Marcos> hehe
# [16:28] <Marcos> anyway, everyone fucks this up
# [16:28] <Marcos> so, we need to be clear. I know it seems simple, and it is simple to fix, but the spec needs to make this clear
# [16:29] <darobin> I think this is a different issue, but I agree that it should be clarified
# [16:29] <Marcos> ok
# [16:29] <darobin> I'm not sure how to phrase it other than "implementation MUST follow the Zip spec, dammit you morons!"
# [16:29] <Marcos> darobin: agreed, it's slightly different... kinda related.
# [16:30] <Marcos> We just need to say that all file names MUST be converted to some default encoding (UTF-16)
# [16:30] <darobin> the problem you describe in that post is that implementations do all sorts of crap in the file field — if they didn't, or if that crap were clearly marked with the right encoding, then we'd be safe
# [16:30] <darobin> that won't solve your problem
# [16:31] <Marcos> right
# [16:31] <darobin> and we shouldn't say anything like that — some languages may implement strings using a variety of encodings and only convert when needed
# [16:32] <darobin> the problem you describe is that zip implementations put crap into the fields — no amount of converting to an internal representation is going to help if you don't know what encoding you're getting in
# [16:32] <darobin> Crap In Crap Out
# [16:32] <Marcos> right
# [16:32] <Marcos> having acquired darobin hit on my blog, we can now forget about my blog entry...
# [16:33] <Marcos> ok, we can't solve the problem on my blog till everyone implements zip correctly. I have come to accept that...
# [16:34] <Marcos> ok, so what you said before about UTF-16 made sense
# [16:34] <tlr> +1 to Brian
# [16:34] <darobin> so, now that that's clear, I'm not sure what we're supposed to put in the spec :)
# [16:34] <Marcos> tell 'em to make that mapping that you said before
# [16:35] <Marcos> all the file names in the package (cp437|utf8) - > UTF16 or whatever
# [16:35] <darobin> so, to sum up: Rules for converting a string to a zip relative path is dropped
# [16:35] <Marcos> right
# [16:36] <Marcos> but we need "A user agent MUST represent zip-rel-paths as UTF-16"
# [16:36] <Marcos> or something
# [16:37] <darobin> and I find somewhere in the spec to add "The name of the files as described by the Zip archive must be decoded and compared as strings, not using the bytes from the Zip"
# [16:37] <Marcos> right, make it more clear than that. e.g. "as a DOMString" or something
# [16:37] <darobin> where should I put that? in "Zip Archive"
# [16:38] <darobin> I would be really cautious about that
# [16:38] <Marcos> ok
# [16:38] <darobin> I think that stating that they should be converted to strings is enough, after that implementations may do smart things to compare strings faster
# [16:38] <Marcos> but "compared as strings" does not mean much.
# [16:38] <Marcos> ok, true
# [16:39] <Marcos> no need for all the dom baggage
# [16:39] <darobin> "the name of the file entry is that which is present in the Zip archive decoded using the correct encoding"
# [16:39] <darobin> can I use CVS for those edits or does that scare you :)
# [16:40] <Marcos> which version do you have?
# [16:40] <darobin> of CVS?
# [16:40] <Marcos> (of the doc) yeah, screw it. lets do this merge business
# [16:41] <Marcos> darobin: have you done any work on the spec today?
# [16:41] <darobin> fuck, there are conflicts!
# [16:41] <darobin> I haven't touched the document yet
# [16:41] <Marcos> ok
# [16:41] <Marcos> let me check in
# [16:42] <Marcos> ok
# [16:42] <Marcos> latest is up
# [16:42] <Marcos> merging should be easier now
# [16:43] <Marcos> should we do a test merge?
# [16:44] <Marcos> I added
# [16:44] <Marcos> <h3>Step 5 Take a deep breath</h3>
# [16:44] <Marcos> <p>Grab a kit kat.</p>
# [16:44] <Marcos> you add something
# [16:45] <darobin> I've committed a change
# [16:45] <Marcos> ok
# [16:45] <darobin> but not on your version with a kit kat :)
# [16:45] <darobin> which I assume is local
# [16:46] <darobin> conflicts normally only happen when you make overlapping changes
# [16:46] <darobin> so committing/updating often tends to help
# [16:46] <darobin> that, and communicating
# [16:47] <Marcos> ok, I just merged
# [16:47] <Marcos> what did you add?
# [16:50] <Marcos> oh no! the document is all screwed up! and the server is refusing to fix it! all versions seem to be corrupt!
# [16:50] <Marcos> jokes
# [16:54] <darobin> hehe
# [16:54] <darobin> I got your kit kat version, and it merged fine
# [16:54] <darobin> now I've added the encoding of file fields stuff
# [16:54] <darobin> (and removed the kit kat)
# [16:55] <darobin> "Note that throughout this specification, manipulations on Zip relative paths must be performed on the string obtained by decoding the file name field using the appropriate encoding, and not on the bytes initially stored in the archive. "
# [16:55] <darobin> which led me to note that we skip from Step 4 to Step 6 :)
# [17:01] <darobin> Marcos: so you can close items #3 and #4
# [17:02] <darobin> all I have left now is <access>
# [17:02] <darobin> what I'll do is that I'll make the small fixes that are agreed to
# [17:02] <darobin> then we can see about killing it
# [17:14] <darobin> Marcos?
# [17:15] <Marcos> darobin: went to get food
# [17:15] <darobin> np
# [17:15] * Marcos catches up
# [17:15] <darobin> in the processing section, there's a lot of stuff and access's @network attribute
# [17:15] <darobin> I'm guessing that old stuff?
# [17:16] <Marcos> yes, that's old
# [17:16] <Marcos> I'm working on that section ATM
# [17:16] <darobin> ah ok
# [17:16] <darobin> I let you fix then?
# [17:16] <Marcos> yes please
# [17:16] <darobin> ok, good for me
# [17:17] <darobin> so you're handling http://www.w3.org/mid/4A060771.5030008@gmail.com I guess
# [17:20] * Marcos takes a looksy
# [17:20] <Marcos> yes
# [17:20] <Marcos> Will take care of that too
# [17:21] <Marcos> Awesome, that only leaves 5, 8 and 16
# [17:22] * Marcos writes into IRC about playing his air guitar, while in reality he does no such thing...
# [17:23] * Marcos notes that authoring requirements are intermixed with element definitions
# [17:23] <Marcos> darobin: should we fix that?
# [17:23] <Marcos> Attributes
# [17:23] <Marcos> id
# [17:23] <Marcos> Optional. A valid URI that denotes an identifier for the widget.
# [17:24] <Marcos> "Optional." here means that it is optional for authors to use that element
# [17:24] <Marcos> not that it is optional to implement
# [17:24] <Marcos> I think we should remove all those "OPTIONAL" and "REQUIRED" from there
# [17:25] <Marcos> and make a little "Authoring Guidelines:" section under each element defintion
# [17:26] <darobin> I thought it was clear
# [17:26] <darobin> if the attribute is present, then the UA must do something about it
# [17:26] <Marcos> and then say, "it is optional for authors to use the following attributes: x, y, z. It is required that authors use the following attributes..."
# [17:26] <darobin> (in A+E at least)
# [17:26] <darobin> I think that's extra work with little actual return
# [17:27] <Marcos> right
# [17:27] <Marcos> leave it for second LC
# [17:27] <Marcos> it's only like 20 mins of work...
# [17:28] <Marcos> as I'm obsessive about such things, I won't sleep till it's done. But will refrain from doing it till we publish
# [17:29] <Marcos> ok, ping me if you need anything
# [17:30] <darobin> will do
# [17:31] <Marcos> darobin: about access processing rules, you want me to write those ?
# [17:32] <Marcos> I.e., if there is more than one access element, ignore it.. etc
# [17:32] <Marcos> and how to derive the values?
# [17:32] <Marcos> or are you going to do that?
# [17:32] <darobin> there can be more than one access element
# [17:32] <Marcos> right, of course
# [17:32] <darobin> well as you like, that's why I was asking about the processing section
# [17:32] <Marcos> bad example :P
# [17:32] <Marcos> sorry, I missunderstood
# [17:33] <darobin> there's oooooold stuff in there
# [17:33] <Marcos> I just trashed it
# [17:34] <Marcos> ok, I can write that part
# [17:34] <Marcos> Seems easy enough
# [17:34] <Marcos> we are getting rid of required, right?
# [17:34] <Marcos> darobin:
# [17:35] <Marcos> ^^
# [17:35] <darobin> I've already dumped it my friend
# [17:36] <darobin> update your copy, there's a whole new <access>
# [17:36] <darobin> it just needs processing rules in the processing section
# [17:38] <Marcos> awesomeness
# [17:46] * Quits: smaug (chatzilla@82.181.149.131) (Quit: gecko update)
# [17:52] * Joins: wellington (chatzilla@201.43.142.174)
# [17:55] <Marcos> darobin, i think you were right in saying that access@uri should really be @pattern
# [17:55] * Quits: wellington (chatzilla@201.43.142.174) (Quit: ChatZilla 0.9.84 [Firefox 3.0.10/2009042513])
# [17:55] <darobin> no I wasn't, I changed my mind :)
# [17:56] <darobin> it contains URI or *, so it's not really a pattern
# [17:56] <darobin> it used to be — but not since we have @subdomain
# [17:58] * Joins: arve (arve@84.202.133.45)
# [18:00] <darobin> Marcos: as far as I can tell, my P+C actions are done
# [18:00] <Marcos> darobin: nice one
# [18:00] <darobin> that is, unless we actually come to a resolution on <access>
# [18:04] * darobin dumps extra work onto an unsuspecting Arun
# [18:05] <darobin> Marcos: do you want me to do a quick editorial pass through the spec, or is it too early for that?
# [18:05] <Marcos> you can check anything in green
# [18:05] <Marcos> basically
# [18:05] <darobin> ok
# [18:29] * Joins: smaug (chatzilla@82.181.149.131)
# [18:33] <darobin> Marcos: in Zip Relative Paths the authoring guideline says "Try to keep path lengths below 255 bytes." but the rest of the section talks of a 250 bytes limitation
# [18:33] <Marcos> argh
# [18:33] <Marcos> will change to 250
# [18:33] <Marcos> darobin: are you making editorial changes as you go?
# [18:33] <Marcos> or just reading?
# [18:34] <darobin> making
# [18:34] <Marcos> oh ok
# [18:34] <darobin> I'm changing it
# [18:34] <Marcos> ok, change away
# [18:35] <darobin> fuck, it's raining like mad here
# [18:35] <Marcos> but please keep some kind of high level record of what you are changing... the gods are angry you are changing my words!
# [18:36] <tlr> darobin doesn't fear devil nor deity, but rain
# [18:36] <darobin> now it's hailing big chunks of ice — that you can surely fear
# [18:36] <darobin> Marcos: the changes I've been making are really basic
# [18:36] <tlr> dices of ice
# [18:36] <darobin> like plurals in the wrong place, repeated words, etc
# [18:37] <darobin> so I'm being faithful to what you wanted to say — I'm just fixing the bugs :)
# [18:37] <Marcos> no probs, that's great... I'm totally dyslexic, should have never been allowed near a spec :)
# [18:37] <darobin> "One or more start files, located at the root of the widget package and/or at the root of locale folders."
# [18:38] <darobin> can't they actually be anywhere using content@src
# [18:38] <darobin> pretty damn fine job for a dyslexic :)
# [18:38] <Marcos> right, that needs to change
# [18:38] <Marcos> thanks!
# [18:39] <darobin> I think in that section we can just remove ", located at the root of the widget package and/or at the root of locale folders."
# [18:39] <darobin> except for signatures and the configuration doc
# [18:39] <Marcos> ok
# [18:45] <darobin> "If using [SVG] as an icon format, create icons that use declarative animation."
# [18:46] <darobin> I'm guessing there's a missing "and you intend it to be animated"
# [18:46] <Marcos> right
# [18:46] <Marcos> darobin, it was meant to say that authors should not use scripted animations, etc.
# [18:47] <darobin> yes, gotcha, it's just that as is it seems to say that you should do animated rather than static :)
# [18:47] <Marcos> i see. certainly not what I meant
# [18:47] <Marcos> ...though a hundred spinning 3d icons on my phone would look awesome and would surely impress girls at the bar
# [18:48] <darobin> rofl
# [18:50] <darobin> User agents must treat files in an arbitrary folder or locale folders that use the file name config.xml as an arbitrary file.
# [18:50] <darobin> Note: The user agent will teat any configuration document not at the root of the widget package, or not at the root of a locale folder, as an arbitrary file.
# [18:50] <darobin> dropping the Note :)
# [18:50] <Marcos> right
# [18:51] <darobin> "Only place configuration documents in localized folders if the content of the configuration document has been localized."
# [18:51] <darobin> we killed that, right?
# [18:51] <Marcos> right
# [18:51] <Marcos> kill it
# [18:51] <Marcos> only on cofig doc in this version
# [18:57] <darobin> "A path can be either absolute, meaning that it is already resolved to the root of the widget package (e.g. "/images/bg.png") or relative, meaning that it is resolved relative to the base folder."
# [18:57] <darobin> kill, right?
# [18:58] <Marcos> darobin: crush, kill, destroy (in that order)
# [18:59] <darobin> general consistency note: on some elements we say that xml:lang may be present, on others we say nothing
# [19:00] <darobin> in truth, it can be present anywhere but may have no effect as per this spec
# [19:00] <Marcos> right
# [19:01] <darobin> not sure if that warrants an edit or not
# [19:01] <darobin> "Localizable via xml:lang: Yes, but the value of the xml:lang attribute must be unique for any subsequent element of this type."
# [19:01] <darobin> that's a CC claim, not sure about it
# [19:01] <darobin> but minor issue
# [19:01] <Marcos> agreed
# [19:02] <Marcos> it's both a cc and authoring guideline
# [19:02] <darobin> anyway, I have to leave now — I've made editorial fixes up to <name>
# [19:02] <darobin> nothing huge, apart from the things discussed here it's all about typos
# [19:03] <Marcos> darobin: great, thanks
# [19:03] <Marcos> you checking in?
# [19:03] <darobin> done
# [19:03] <Marcos> ok, cool. I'll merge now
# [19:03] <darobin> I'll finish my pass tomorrow morning
# [19:03] <Marcos> np
# [19:07] <Marcos> darobin: fuck, now it's complaining that it can't merge
# [19:09] <Marcos> darobin: yt?
# [19:09] <darobin> mmmm, you getting a confluct?
# [19:09] <Marcos> yah
# [19:09] <darobin> grep for <<<<<
# [19:10] <darobin> or >>>>>
# [19:10] <darobin> that'll give you the conflict boundaries
# [19:10] <darobin> I only touched green sections, and at the beginning of the document
# [19:10] * Quits: trackbot (trackbot@128.30.52.30) (Connection reset by peer)
# [19:10] <Marcos> ah, I see
# [19:14] <darobin> sorry, gotta go
# [19:14] <darobin> is it a big conflict?
# [19:14] <darobin> did you edit anything above <name> in the past hour or so?
# [19:14] <darobin> normally there will be <<<<< ... ===== .... >>>>>
# [19:14] <darobin> and what's on either side of the ==== are the two versions that can't be merged
# [19:14] <Marcos> yeah, I found those
# [19:15] <darobin> (there can be several of those in the document)
# [19:15] <darobin> which are they?
# [19:15] <Marcos> A keyword is a string that is reserved for the purpose of this specification. The value of a keyword attribute is a keyword that is one of a finite set specified in the attribute's definition (e.g. the its:dir attribute defines ltr, rtl, lro, or rlo as its only possible values). Authors must use keywords in the case given in this specification. Implementations must only perform literal comparisons on the resulting value, and must not use case =======
# [19:15] <Marcos> A keyword is a string that is reserved for the purpose of this specification. The value of a keyword attribute is a keyword that is one of a finite set specified in the attribute's definition (e.g. the its:dir attribute defines ltr, rtl, lro, or rlo as its only possible values). Authors must use keywords in the case given in this specification. Implementations must only perform literal comparisons on the resulting value, and must not use case >>>>>>> 1.242 i
# [19:15] <darobin> you edited that?
# [19:15] <Marcos> An attribute defined as containing a valid path. A valid path is one that <<<<<<< Overview.src.html matches the path token as defined in the [URI] specification. A path can be either absolute, meaning that it is already resolved to the root of the widget package (e.g. "/images/bg.png") or relative, meaning that it is resolved relative to some base.
# [19:15] <Marcos> ======= matches the path token as defined in the [URI] specification. >>>>>>> 1.242
# [19:16] <Marcos> don't think so
# [19:16] * Joins: trackbot (trackbot@128.30.52.30)
# [19:16] <darobin> okay, for the first one my change was to move <code>defines ltr to defines <code>lrt
# [19:17] <darobin> in the second one, I just killed "A path can be either..."
# [19:17] <darobin> that's weird, it really shouldn't conflict unless you made a change too
# [19:17] <Marcos> dunno, I told you all this merge stuff was just voodoo
# [19:17] <Marcos> :)
# [19:17] <darobin> so what you do now is fix those by removing the <<< >>> etc and putting in the right thing
# [19:17] <Marcos> evil, evil voodoo
# [19:18] <Marcos> ok, will do
# [19:18] <darobin> then there's going to be a file called ".#Overview...." which you'll want to remove
# [19:18] <darobin> then commit that and all should be fine
# [19:18] <darobin> CVS is fucked up, I wish we used git or svn
# [19:18] <Marcos> ok, is all good then :D
# [19:18] <darobin> anyway, off I go!
# [19:18] * Quits: darobin (darobin@82.233.247.234) (Quit: darobin)
# [19:38] * Quits: sicking (chatzilla@63.245.220.241) (Quit: ChatZilla 0.9.84 [Firefox 3.5b4pre/20090422042031])
# [22:08] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
# [23:03] * tlr tries to contain laughter at Arun's latest.
# [23:30] <Hixie> which list?
# [23:35] <tlr> https://twitter.com/arun/status/1787778325
# [23:36] * Quits: arve (arve@84.202.133.45) (Ping timeout)
# [23:40] <Hixie> aah
# [23:41] <Hixie> the one place i didn't think to check!
# [23:42] * Quits: tlr (tlr@128.30.52.30) (Quit: </today>)
# [23:48] * Joins: darobin (darobin@85.169.117.248)
# Session Close: Thu May 14 00:00:00 2009

The end :)