02:40 <bjoern_> you might want to localize the text for a11y reasons, etc 02:40 <bjoern_> it's not clear whether / to which extend this would be allowed 02:40 <bjoern_> and whether this could require more characters for the included font subset 02:41 <xover> Hmmm. And it currently looks like we have to roundtrip each such change through Comms. Right. 02:42 <xover> I don't know enough about SVG to comment usefully.

01:08 some agenda at http://esw.w3.org/topic/QaDev 01:12 JibberJim, niq, I was thinking we could check the EARL requirements draft together, see if there is anything relevant for the tools at the moment 01:14 it's at internal draft so far, I had misread it as being a TR working draft, but still 01:14 http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Requirements-20050624.html 01:14 should be working draft soon. 01:14 hmm, there's a schema too 01:14 without any changes. 01:16 bjoern_: any thought on how the observation model drafted in m12n doc with regards to EARL? 01:17 the two seem to have quite common goals and mechanisms 01:17 well, I'd describe them as completely orthogonal, but they probably aren't. 01:18 orthogonal? maybe they complete one another, but they didn't seem orthogonal to me 01:20 well, maybe. I trust there is some useful mapping from the m12n stuff to some kind of EARL. 01:23 niq, JibberJim: are there also changes to the schema yet, and if so, is it worth changing our implementation in the Markup Val now? 01:24 I don't think just yet, certainly we should wait until the draft is out, which will probably be by the next meeting, I think voting for it is on next weeks agenda. 01:25 the schema has changed yes. 01:25 okay 01:27 I guess we'll keep an eye on it, please ping whenever it's a good time to give it a look, here or public-qa-dev@ 01:27 launching a Beta test of Markup Validator 01:28 got zero feedback so far on the alpha2, so was thinking widening the audience with a first beta would be a logical next step 01:29 unless someone disagrees 01:29 no disagreement 01:30 0.7.0 metabug has just http://www.w3.org/Bugs/Public/show_bug.cgi?id=1399 01:30 scop, did you have a chance to install it yet? 01:30 yes, 1399, I hope to make progress on this now that I have made updates to other docs (about and FAQ) 01:31 one thing that would really be nice to have soon would be a win install doc, though 01:31 bjoern_, you didn't get any answer from David Tibbe? 01:31 yod, nope, not yet :( 01:31 + bjoern_ did not ask yet... 01:32 BZ1399 is not a bug; it's a political agenda. I can live perfectly happily with it unresolved until added conformance checking in WMVS makes it obsolete. 01:32 xover++ 01:32 for the record, other currently 0.7.0-targeted bugs: http://www.w3.org/Bugs/Public/buglist.cgi?product=Validator&target_milestone=0.7.0&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED 01:33 scop: one thing I meant to ask, we should perhaps upload an updated bundle 01:33 would make it easy to install the HEAD 01:33 yod, that I can do in a jiffy 01:33 would be cool 01:34 will upload tonight 01:34 anyone remembers whether we had provided tarballs of previous betas? 01:34 yep, we did 01:34 xover: I agree it's not a blocker, but honestly think the tagline could be improved, and that's as good a pretext as any, no? 01:35 scop, hmm, OK, will create some for this time too then 01:35 + scop will check that misc/mkrelease.sh in HEAD does the right thing 01:35 yod: Not really, no. Any text coming out of that bug is absolutely guaranteed to suck badly. 01:36 + bjoern_ basically agrees... 01:36 bjoern_, niq: cf. Bug #66; close as WONTFIX? 01:36 hmm, Bug #13 should be fixed now, I don't remember if I uploaded my changes 01:37 I'd think this will become obsolete by using a real XML processor... 01:37 right 01:37 I'd prefer to keep it open so we don't forget the issue... 01:37 yod, #13 has a reproducer in the URL field, the caveat appears to be there 01:38 scop, right - thanks 01:38 + xover seems to recall a CVS checkin from yod to fix that issue a while back... 01:38 I remember why I left the issue open, the Note: needs a bit of styling 01:39 it's almost unnoticeable ATM 01:39 Does it need to be different from any of our other warnings? 01:39 (slightly off topic): what's this? http://qa-dev.w3.org/wmvs/HEAD/check?uri=http%3A%2F%2Fdeveloper.classpath.org%2Fdoc%2Fall-packages.html 01:39 local sp problem on qa-dev? 01:40 good question... I remember noodling about this and thinking that it was a warning about the validator, not about the document validated 01:40 yod: To fina distinction methinks. 01:40 the validator does not support relative system identifiers 01:40 scop: Fubar URL in the ... right, what bjoern_ said. 01:40 so they are resolved locally in the file system 01:40 where we do not allow access 01:41 oh, I see. I thought I had tested alpha2 at v.w.o:8001 and that it worked there, but memory doesn't seem to serve me right 01:41 and we don't "know" the FPI 01:43 + xover retargets and reassigns BZ#66. 01:43 hm, no open bug reports found with "relative" - but I gather this is a validator problem, not sp? 01:43 Re: Bug #1399, I can live with a "no consensus on how to fix this at the moment" and remove from metabug dependency 01:43 s/how/how and whether/ 01:43 scop: SP problem triggered by the way WMVS uses it. 01:43 Any resolution is bound to come from bjoern_'s S:P:O code. 01:44 (or at least "by way of") 01:44 I tried playing with the formal stuff, there is a base attribute but it did not work as intended... 01:45 yod: Target it for 1.0 and leave it for now. 01:45 xover, ok, fine with me 01:45 filed as #1521 01:48 alright 01:48 xover bjoern_, niq: cf. Bug #66; close as WONTFIX? <--- as formulated, it's an OpenSP bug, not a validator one. Can/should validator work around it 01:48 + niq only half here 01:48 Just one note on 0.7.0 (including beta); make it very very low-key; there is very little in there that's much use to end users, and it fails to deliver on I18N. Leave high-profile for when we actually have something to show. 01:49 xover, you're right in terms of "stuff to show", but we should get wide-enough testing 01:50 re #66, well, I don't care much really. 01:50 yod: Agreed. We just need to manage expectations. 01:50 right 01:51 would anyone mind doing "mv en_US en-us" in the CVS repo before the beta? 01:51 niq: I'm inclined to agree with bjoern_; leave it open because the effect affects us, but aim the fix to be using a real XML Processor (OpenSP is a lost cause for XML). 01:51 scop: Yes, because CVS moves are high-treshold; do we really need to? 01:52 moving in CVS is a pain... either you risk losing history or you annoy people with a checkout 01:52 well, do we want to map conneg in the future to dir names? 01:52 Yes. 01:52 Let me rephrase... 01:52 could copy the ,v files into a new dir and then cvs remove the old one 01:52 xover, ha, you beat me to it :) 01:53 yod, right, that's why I asked if anyone would mind... it won't get easier than now 01:53 I have no objections so long as you feel confident the current setup is wrong, and you're fairly certain about how it should be in the future (for all probable use cases). 01:54 The specific case I'm worried about is the vague idea of using those directories, i.e. faux locales, to provide e.g. EARL, XML, etc. output. 01:54 But bottom line, feel free to do what you think is best. 01:54 I'm confident that en_US is not useful, but of course I cannot predict the future 01:55 yod: Lay off futzing with repo files. It's a hack and should be done only when absolutely necessary. 01:56 hmm, copying files is hardly a dangerous hack... I'm not talking rewriting history here, just working around one limitation of CVS 01:57 scop: I entirely trust your good judgement on this. I just wanted to make sure you considered the points 1) CVS moves are non-neglible, and 2) we may want do do some oddball things with the dirs. 01:58 xover: were you thinking of having subdirs within the "locales", one per format? 01:58 just curious 01:59 Yeah. Well, not necessarily subdirs for XML and EARL etc., as those don't strictly need it; but "various" oddball ways to abuse faux locales to achieve that kind of thing. 02:00 hm, I took a peek into CVS, and it appears files below en_US do have < 0.7.0 tags in them 02:01 so, suggestion withdrawn. if necessary, we can take care of renaming eg. while creating the dist tarball or something 02:01 fair enough 02:02 so, ACTIONs... 02:02 ACTION scop to upload an updated, 0.7.0-friendly Bundle to Pause 02:02 ack 02:03 ACTION scop to check mkrelease for 0.7.0-friendliness 02:03 ack2 02:03 ACTION yod to (subsequently) create tarballs of 0.7.0 validator and sgml-lib 02:04 ACTION yod to prepare 0.7.0 beta announcement, find balance between getting wide testing but no excessive hype 02:04 ACTION bjoern_ ask David Tibbe about Win/IIS installation guide in en 02:05 Where is the SWLInux issue being tracked? 02:05 Or SELinux, even. 02:05 on the list so far 02:05 FC/FE Bugzilla? 02:06 + xover isn't on the swlinux list 02:06 + scop searches 02:07 (despite actually having a patch in there, as I recall) 02:07 https://www.redhat.com/archives/fedora-selinux-list/2005-June/msg00264.html 02:07 https://bugzilla.redhat.com/149454 02:07 (from scop's latest on the issue http://lists.w3.org/Archives/Public/public-qa-dev/2005Jun/0026.html ) 02:08 http://cvs.fedora.redhat.com/viewcvs/rpms/w3c-markup-validator/devel/w3c-markup-validator.spec?root=extras&r1=1.4&r2=1.5 02:09 even if we could not actually _install_ policy modules cleanly until FC5, we could come up with such a module already and include it in the package as documentation 02:10 true 02:10 I think that would be ok in the sense that the FC < 5 package could be re-enabled 02:11 + xover needs to read up on current status of SELinux... 02:11 Aren't contexts set in the file xtarrs? 02:12 + xover also needs to learn how to type, apparently... 02:12 ACTION scop to figure out how to install wmvs 0.7.0 on FC3+ and SELinux enabled 02:12 I don't know it that well either 02:13 (but somewhere in the FS's file attributes, yes) 02:14 So we should be able to do quite a lot by shipping the RPM with the right contexts set, no? 02:14 the problem is persisting them 02:14 RPM doesn't grok xattr sufficiently? 02:15 it does, but a frequent advice when things go wrong is "relabel your filesystem" 02:15 ...which, I gather, blows away everything that's not in the SELinux policies 02:16 (apart from local customizations) 02:16 + xover sighs... 02:16 That's a fixfiles bug; it shouldn't nuke contexts on files it doesn't know about. 02:16 it knows about _every_ file's context ;) 02:17 In any case, it looks like this really does need more study before any more guessing is worthwhile. 02:17 install selinux-policy-targeted-sources and check out the regexps in *.fe (or was it *.fc) below /etc/selinux/targeted/... 02:18 xover++ 02:18 Do I recall you taking the AI on that scop? :-) 02:18 +1 for more study, experiment 02:18 AI yes, I am more or less "obliged" to do it anyway, I'm the maintainer of the package in fedora extras... 02:25 we should discuss the svg badge issue 02:25 so we can write the comm team back 02:26 fine with me 02:26 (http://lists.w3.org/Archives/Public/public-qa-dev/2005Jun/0024) 02:26 thanks, I was looking for a pointer 02:26 + xover haven't had a chance to think much on that... 02:26 [10:09] Hmmm. I wonder if there is any practical way we can leave Comms with control of the W3C ligature while allowing the .svg files themselves to be modified at will... 02:26 [10:10] A combination of an OSS Copyright license with restrictions in Trademark/Trade Dress country perhaps? 02:27 + yod disclaims he worked with comm on this topic 02:28 scop: How does the W3C Logo Trademark jive with FC trademark policy for the RPMs? 02:28 if my interpretation of logo policy is correct, any icon/graphics with the W3C logo in it is untouchable, unmodifiable 02:28 which means, if I am not mistaken, that they can't be distributed with an OSS license 02:28 xover, funny you should ask, I just queried trademark stuff yesterday (or a couple of days back, hold on a bit) 02:29 Should we ditch the W3C logo? 02:29 re: trademarks, see thread at https://www.redhat.com/archives/fedora-extras-list/2005-July/msg00161.html 02:30 Perhaps try to persuade them that the logo is an #include int SVG (analogous to ) and used in accordance with policy bit which lets you use the logo to refer to W3C sites or standards? 02:31 that thread is about package summaries and descriptions though, dunno how/if it applies to eg. the logos 02:31 RH bases the insane price of RHEL on the protection the included RH logos and TM enoy. 02:32 I see the list archiver has dropped a couple of 'Ž's from my message :( 02:32 I.e. respins such as CentOS can do what they do because the remove the redhat-artwork RPM (and a few other things). 02:33 anyway, my gut feeling is that the logos won't be a problem in FE 02:33 So your few thousand dollars buys you... A 72KB GIF of the shadowman logo. :-) 02:34 --> Insufficient data for conclusion. Needs further thinking? 02:34 seems so 02:35 I can ack for the group, ask for more time 02:35 bjoern_? 02:35 and ask comm when an answer would be needed 02:35 fine with me 02:35 but I note that our delay will add to existing/other ones 02:35 there are some translation issues that should be looked at aswell 02:36 translation? 02:37 yeah, the proposal does not cover them at all 02:37 (l10n if that wasn't clear) 02:37 oh, ok 02:38 Which proposal? 02:38 Ian's 02:38 http://lists.w3.org/Archives/Public/public-qa-dev/2005Jun/0024 02:39 + xover fails to connect the dots leading to l10n there... 02:39 you might have e.g. a in the svg with natural language 02:39 or a 02:40 <bjoern_> you might want to localize the text for a11y reasons, etc 02:40 <bjoern_> it's not clear whether / to which extend this would be allowed 02:40 <bjoern_> and whether this could require more characters for the included font subset 02:41 <xover> Hmmm. And it currently looks like we have to roundtrip each such change through Comms. Right. 02:42 <xover> I don't know enough about SVG to comment usefully.