00:08:02 gavin has joined #html-wg
00:27:36 Zeros has joined #html-wg
01:07:54 DougJ has joined #html-wg
01:11:07 [05:31] Does anyone actually implement new versions of XSLT?
01:11:35 I've used XSLT2 extensively. In fact, I couldn't bare to use XLST1 anymore, it just misses too much that I've gotten used to :)
01:13:21 [04:21] Hixie, do you take special classes on how to be rude, or do you just do it naturally?
01:13:22 ehehe
01:14:10 there's a fad with making sarcastic remarks about the W3C efforts nowadays, it's honestly not that bad, if perhaps not directly applying to the goals of HTML5
01:15:01 but anyway
01:21:18 Grauw: I don't think Hixie is the only one to think the TAG's findings are of questionable value
01:21:25 I'm not saying he is
01:21:43 saying that there's a 'fad' implies that there are more than one people doing it :)
01:21:52 I completely disagree with a whole bunch of the findings.
01:22:03 'fad' implies that (a) it's invalid and (b) it will pass
01:23:34 let's rephrase it then, I think there's a lot of criticism on W3C specs and effort on small details, and specs as a whole are named worthless for that
01:23:56 whereas the specs as a whole are pretty nice
01:24:22 e.g. XHTML2 introduces a lot of nice things, so within its own space of existence I would say that you could call it a nice specification
01:24:50 XHTML2 is a bunch of bad ideas poorly specified
01:25:15 to call it a "nice specification" you have to water down the meaning of that phrase a lot
01:25:36 however some people are critisising that it doesn't specify every implementation detail, and discarding the entire spec or the ideas in it as bad
01:25:46 or at least make it sound like that, and cause other people to do so
01:26:36 I think many of the ideas in it are also bad
01:26:39 though some are good
01:26:49 well a lot of it is a matter of perspective
01:26:53 its basic idea of breaking compatibility is bad
01:28:00 if I hear Anne going on about XML error handling it also makes me cringe :)
01:28:21 mjs, maybe, that's the key difference that HTML5 does different
01:28:52 however you should consider the ideas within the space of thought of breaking compatibility (and they didn’t entirely, btw)
01:28:55 anyway
01:28:58 I need to go :)
01:29:05 I'm being called ^_^
01:29:12 later
01:30:40 if you look at them in a vaccuum, xforms is a nice spec. xhtml2 is not.
01:30:41 imho.
01:30:54 xhtml2 leaves far too much very vague and has basically no ua conformance criteria to speak of
01:31:15 (not gone yet) I suppose you could indeed say that XForms is a much better spec than XHTML2
01:32:51 xhtml2 is a bad spec qua spec as well as an unsuitable design for the web
01:32:55 maybe as for XHTML2 what I mean is people should look at the ideas that it has (and people have, you said you have too, and a fair amount ended up in HTML5)
01:33:03 in the case of xforms only the latter is true
01:33:25 I disagree with that :) I don't see how it's unsuitable for the web
01:33:37 but anyway, I need to go, so don't remark on that :)
01:34:44 ideas don't make a spec
01:35:35 Ashe has joined #html-wg
02:00:40 DougJ has left #html-wg
02:15:56 gavin has joined #html-wg
03:03:45 mjs has joined #html-wg
03:09:30 w.r.t. that web architecture document quote, "A data format specification SHOULD provide for version information."
03:10:04 I don't think you can consider CSS a data format. HTML, maybe, but I think whether or not to include versioning information is not a general rule but rather based on a design decision in the language
03:10:31 finally, in most XML-based formats, the XML namespace provides sufficient means for versioning
03:10:58 and no additional version information should be provided. backwards-compatibility breaking changes should change the namespace
03:15:58 sbuluf has joined #html-wg
03:46:51 MikeSmith has joined #html-wg
04:08:18 Zeros has joined #html-wg
04:08:24 Zeros has joined #html-wg
04:17:45 DougJ has joined #html-wg
04:23:44 gavin has joined #html-wg
04:23:50 dbaron has joined #html-wg
04:30:25 mjs has joined #html-wg
04:42:03 I wish people would stop the debate over and . There is no way in hell that a screenreader can know SMIL is to be pronounced like ‘smile’, nor can it know that SQL has to be pronounced ‘sequel’. Unless it has a list of pronounciations built-in, in which case the author doesn’t need to indicate any distinction in the first place.
04:42:44 css isn't a data format?
04:42:45 what is it then?
04:43:01 the only real solution would be to provide an attribute with a pronunciation key in some phonetic alphabet
04:43:36 Hixie: what I mean is that it doesn’t convey information
04:43:44 it merely conveys how to present the information
04:44:01 Grauw: that's why we need to spec in a "phonetic" attribute for , to be specified in IPA symbols
04:44:05 (just kidding)
04:44:18 jjb, yay for unicode ;p
04:44:33 ha, i see you made the joke before i had time to put mine together
04:44:38 I'm all for that, with the proper IPA symbols ;p
04:45:01 in theory, i wouldn't mind that either, but somehow i think it would't pan out so great in the market...
04:45:07 you don't think "i want h1s to be rendered in green" is information?
04:45:08 somehow, ne :)
04:45:28 Hixie, ... I think you’re missing my point :)
04:45:34 yes
04:45:41 i don't understand your point :-)
04:46:37 to me at information is primarily stuff like address information, etc, something you would express with RDF
04:46:54 CSS in itself as a format of course conveys information on the presentation
04:47:01 but it doesn’t carry semantics
04:47:02 you could express CSS in RDF
04:47:16 of course you can
04:47:23 so...?
04:47:23 but you wouldn't :)
04:47:33 I wouldn't express _anything_ in RDF
04:47:43 LOL!
04:48:18 i don't understand why css is different from html in terms of deserving versioning information
04:48:36 I don't think it is
04:48:53 ok then
04:49:09 I'm not trying to make an argument for versioning information, I said it depends on design decisions of the language
04:49:30 and that maybe the reference to ‘data format’ could be interpreted as so
04:49:45 Grauw, when would it ever be a good design desicion to include versioning?
04:49:48 that it would only cover ‘semantic’ information
04:50:28 for implementors versioning sucks, but I think there’s been a fair number of arguments presented where it’s useful as well
04:51:19 even if just so that if you see the document, you know ‘oh it was documented according to this version of the standard. I’ll stick to that than, so that the risk of adding stuff that doesn’t work in the systems it’s intended to be used for is minimal’
04:52:24 why would a specification's version be useful for that? surely you'd want to specify an authoring subset or at most an implementation version
04:52:37 language versions have very little bearing on what set of features authors use
04:53:09 Backbase software has been through three major versions by now, all incompatible
04:53:26 even among minor versions there have been some incompatibilities (unintentionally, I suppose)
04:54:07 the version information is not indicated however, because it simply depends on which version of the library is included, and which namespace is used
04:54:20 right but with HTML you have more than one implementation
04:54:31 so even with one _language_ version you'll have incompatibilities
04:54:38 e.g. as now with CSS and HTML and DOM and JS and so forth
04:54:41 yeah, so that’s why it’s a per-language consideration
04:54:45 no
04:54:51 it's a per IMPLEMENTATION consideration at most
04:55:16 ...depends on how well the implementations are done, I think.
04:55:29 with the browsers, we got unlucky in that it’s kind of a mess
04:55:30 versioning works if its enforced in the implementation
04:56:05 but if you look at internet standards like IP, etc
04:56:14 you can’t really implement it ‘incompletely’
04:56:36 If Javascript 2 only works when you specify that version there's no room for erroneous mixing in features, and you can fix things later with explicit reference to what set of features you're using
04:57:33 a problem with a lot of ideas that some people have (like anne's xml-should-have-error-recovery) is that it’s a view that really doesn’t apply to all areas
04:58:02 Some XML implementations have some level of error recovery :)
04:58:04 e.g. programming languages are usually not forgiving in their syntax error handling, yet they have been used widely and it forms no obstacle to programmers (rather, a help)
04:58:19 Webkit doesn't show a yellow screen when it sees a malformed document
04:59:01 Grauw, the counter argument is that all media decoders (mp3, video etc.) implement error recovery when the file is malformed
04:59:02 XML is very often used to contain a programming language as well, and for data I also think it would be bad to allow the risk of data being incorrectly error-corrected to say something else than that it actually was supposed to mean
04:59:32 so it’s very specific to the domain
04:59:44 same is true for versioning information I think
05:00:05 or feature indication (pretty much the same thing, but more flexible)
05:00:41 Zeros, WebKit does show an error for malformed content (although it's not yellow like Mozilla)
05:01:01 Lachy, it shows the page rendered up until that point, mozilla shows nothing but the error
05:01:05 Zeros, yeah, I hate malformed MP3s with their stupid pops
05:01:15 if they just didn’t work at all, people wouldn’t share them
05:01:21 and I wouldn’t be bothered by them
05:01:22 Lachy, One is better for programmers, the other for users
05:01:27 oh, I see what you mean
05:02:11 I think both approaches are ok, as long as there’s something that forces the programmers of the backend to implement something that never generates invalid XML
05:02:29 DougJ has joined #html-wg
05:02:59 unfortunately, that doesn't always happen in reality
05:03:20 if all browsers support XHTML, it will, for sites that serve XHTML
05:03:24 There's plenty of systems out there that claim to support XML, but only have tag soup parsers
05:03:30 Lachy, The major issue I think is that XHTML is trivial to hand author and generate invalid results
05:03:33 because they’re forced to, in the same manner as programmers are forced to make sure their code compiles
05:03:42 anyway, have to go (again), I’ll read the backlog when I get back :)
05:03:50 Its more complicated for your word document to become invalid, so most word documents are valid
05:03:55 e.g. feed readers, mobile phones, etc. all use tag soup parsers for XML
05:04:13 With XHTML its pretty easy to introduce an anomaly which would invalidate the entire document.
05:04:24 my feed reader (Sage) uses a true XML parser, and it works just fine (most of the time ;p)
05:04:32 there are many that don't, though
05:04:40 libxml2 works pretty well :)
05:04:59 sure, and I don’t think that’s a good thing
05:05:00 anyway
05:07:26 How long does it usually take for sysreq to respond?
05:08:00 DougJ has left #html-wg
05:08:54 Zeros, what's your real name, or the name you use on the mailing list?
05:10:24 I'm not on the list yet, I filled out the form and realized I entered my last name twice.
05:10:31 Was going to join
05:10:54 Can you fix it?
05:11:11 no, ask Dan or Karl
05:11:20 alright, thanks
05:11:40 typing /whois says your name is Elliot. What's your last name?
05:11:46 Elliott Sprehn
05:12:18 and you?
05:12:22 Lachlan Hunt
05:13:02 I guess I'm not anyone
05:53:24 the logs from in here last night are funny :-)
05:53:41 especially the stuff about the TAG
06:16:59 marcos has joined #html-wg
06:30:13 gavin has joined #html-wg
06:50:33 DougJ has joined #html-wg
07:56:31 chaals has joined #html-wg
08:10:55 That removing namespace-well-formedness in XML somehow makes documents no longer trustable is a myth. If a document needs to be trustable you verify whether or not it meets your criteria. You can't trust a document solely based on the syntax. That'd be silly.
08:11:25 anne has left #html-wg
08:13:05 anne has joined #html-wg
08:29:17 ROBOd has joined #html-wg
08:38:13 gavin has joined #html-wg
09:04:18 anne, I’m not saying that you should trust a document based on the syntax. I am saying however that if there’s something wrong with the document, it’s better if it fails with an error than that it silently tries to recover it (very possibly incorrectly), and the source is never notified of the problem
09:06:14 when it’s meant to be read only by a human (e.g. HTML), it’s less of a problem, because if a human sees, say, that a whole paragraph is linked instead of a certain phrase (because an tag was forgotten), he’ll think it quirky but will understand that only the first part was supposed to be linked.
09:07:06 a computer however would consider the whole rest of the paragraph to be part of the link description
09:08:07 HTML recovers from errors, XML does not. Let the people who want error recovery just use HTML and let’s keep XML simple the way it is :).
09:09:13 it’s not as if XML doesn’t define error handling; it just has very strict (and simple) rules for error handling, similar to say, every programming language out there, or any file system, or any database format
09:09:47 try writing a bunch of corrupted bytes into a MORK file and see if it still works :)
09:10:01 it’s not uncommon practice at all, and it’s not a bad practice either
09:10:36 I'm not really convinced by your argument.
09:10:47 If there's consistent error handling what's the problem?
09:11:00 because the error is a condition that should not be there in the first place
09:11:16 Why should be strict on syntax but loose on conformance?
09:11:18 it signals that there’s something wrong, and ignoring it and just going on as if nothing happened doesn’t indicate the error
09:11:31 s/should//
09:12:13 loose on conformance? that’s up to the language that is implemented
09:12:57 for a data file format (what XML was originally envisioned for, I think), I don’t think you would want anything but strict error handling
09:13:30 and for XHTML, well, it’s in my experience a really nice way to find out some obvious errors that you made, which could otherwise bite you later on
09:13:32 Seeing the feeds deployed on the web I think you do want "graceful" error handling
09:14:02 Also seeing the XHTML deployed by the way... Event the application/xhtml+xml sites very often have character encoding issues.
09:14:09 s/Event/Even/
09:14:18 the problem is that if the user agent doesn’t implement the file format correctly, it doesn’t
09:14:44 define error handling conditions as much as you want, a user agent that uses a regular expression to filter out the bits of an XML file still won’t get it right
09:15:01 Regular expression?
09:15:10 there’s plenty of feed readers which do that
09:15:53 if they would use a real parser (e.g. in Java or .NET or PHP), all of them break on error conditions
09:16:00 Oh, I'm talking about the survey done on feeds some time ago and experience people involved in feeds have shared so far.
09:16:55 if validators use a real XML processor, then feeds must be valid XML
09:17:05 if they are not, then they are not an XML file format, but something like HTML
09:17:11 the parsing rules would depend on the user agent
09:17:19 not on any specification
09:17:58 if you define error handling cases for XML, the parsers that don’t get it right now, will still not get it right if you specify error handling cases (because they just do their own thing and don’t implement any specification)
09:18:15 if they had done so in the first place, there would never be so much invalid feeds around on the net
09:18:43 and anyway, sites who serve feeds can be notified of the problem, it’s a matter of evangelisation I’d say
09:19:20 anyway, my point is: the XML error handling rules are VERY simple. Making them more complex isn’t going to get more UAs to implement them correctly. If anything, less.
09:19:36 Graceful error handling isn't necessarily harder.
09:20:04 Grauw: having done standards evangelization for the Mozilla project long ago, my faith in the power of standards evangelism is not very high as a solution to problems like this
09:20:15 I also share that concern.
09:20:23 it doesn’t serve a purpose, if there is strict error handling then authors are enforced to serve correct XML
09:20:51 Especially with all the people advocating valid HTML code having an incorrect site themselves...
09:20:55 if the XML is invalid then you cannot be sure the error handling corrects it properly
09:21:06 I don’t :)
09:21:21 You can never be sure.
09:21:25 because I use XHTML at least I don’t make obvious mistakes like forgetting a :)
09:21:37 You also can't be sure the parser correctly rejected your content.
09:21:52 it’s like a programming language: there being syntax checking and type checking doesn’t guarantee that your program is good or well-written
09:22:09 it does help you catch a lot of obvious errors though
09:22:11 Or did not reject your content when in fact it should. (A common problem with today's browsers.)
09:22:37 on my website there’s in fact two layers of XML parsers that check it, the backend and the browser itself
09:22:42 A conformance checker helps you with that and more.
09:22:56 (I wasn't talking about your website specifically.)
09:22:59 a conformance checker exists on an entirely different layer
09:23:05 it isn’t immediate
09:23:13 It could be
09:23:14 people run it after developing the site as an afterthought
09:23:21 and don’t run it again everytime new content is added
09:23:33 That entirely depends on how you do things.
09:23:44 If they don't doing just syntax checking on new content doesn't help much.
09:23:48 imo
09:23:48 XML does it inherently
09:24:05 No, XML only checks some syntax of which some isn't even enforced in all browsers.
09:24:29 You can't really buy anything with that.
09:24:30 besides, if the parser doesn’t reject the XML, it’s a parser bug. Defining graceful error handling rules isn’t going to improve that situation because the parser doesn’t follow the spec!
09:24:53 browsers isn’t the only thing out there
09:25:20 I'm not sure I ever argued otherwise.
09:25:34 the fact that some browsers may implement some parts of XML badly doesn’t make it useless, or a failure
09:25:47 Grauw: I wouldn't be too surprised if even Xerces-J didn't properly enforce well-formedness for non-UTF-* documents
09:26:10 It makes it a failure on lots of mobile content and lots of feed content.
09:26:14 Sadly.
09:26:46 the thing is that XML works great as long as you don't expose authors to it or put it on the Web
09:27:04 so pointing to bad implementations, how exactly does that make ‘graceful’ error handling better? an error is an error.
09:27:11 XHTML and RSS are the cases where people start to complain about this
09:27:20 that’s a good thing
09:27:23 the enterprise integration use cases are fine
09:27:27 it finally forces people to pay attention
09:27:32 Also, again, there's not much point in enforcing strict syntax if you don't enforce all the other things a document needs to conform too as strict as well. (And that's impossible for XHTML for instance and any other language that allows embedding script.)
09:27:47 I wouldn’t say there’s no point
09:28:03 for one thing, XML lives on a different layer than the document language on top of it
09:28:16 breaking XML well-formedness breaks any type of processor
09:28:56 I mean, you don’t go blaming IPv4 for errors in HTML documents either
09:29:03 Not for syntactically correct content, but yes.
09:29:47 I would say that HTML syntax and XML syntax are on the same layer more or less...d
09:29:53 s/...d/.../
09:29:55 or rather, I do not expect IPv4 to be ‘lenient’ in some unpredictable way (and instead of rejecting bad packets routing them anywhere based on a guess) just because there are bad HTML documents out there
09:30:09 syntax, yes
09:30:17