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 SGML too 09:30:19 AFAIK authors don't have to deal with IPv4 so that seems fine. 09:30:30 SGML is pretty much dead. 09:30:38 beside the point :) 09:31:06 it’s on the same layer, HTML syntax is a variant of SGML and XML is a variant SGML too 09:31:25 however the language that uses XML (tons) or the language that uses HTML syntax (HTML itself) are on a higher layer 09:31:36 XML is actually a subset iirc 09:31:49 last I read it wasn’t entirely SGML-compatible 09:32:04 but I might be mistaken, anyway, subset falls under the variant nomer I think :) 09:32:29 higher layer, just like the Java API is on a higher layer of the Java syntax, yet it’s also part of the same language 09:32:35 I'm not sure why "higher layer" matters here. 09:32:39 s/of/than 09:32:47 It's the syntax you use as author. 09:32:56 XML is used in a lot more ways than HTML alone 09:33:01 The language itself would actually be the "higher layer" imo... 09:33:09 for a lot of applications of XML, strict error checking is simply inappropriate 09:33:27 for XHTML, strict error checking is a good thing as well I think 09:33:32 it avoids a lot of problems 09:33:36 not all, but a lot 09:33:38 Which problems? 09:33:44 forgetting an tag 09:33:47 It only avoids some syntax problems... 09:33:58 Which are obvious when you make them anyway... 09:34:20 I’ve seen plenty of sites / blog posts where an entire paragraph was a link because people forgot an 09:34:27 Grauw: do you mean that there are cases when a DTD-valid XML document is not an SGML + Annex K document? 09:34:48 hsivonen: you tell me, I don’t know, I just think I read it somewhere :) 09:34:55 Grauw, prolly with an XHTML DOCTYPE 09:35:03 or posts where the in a list was forgotten, causing the indenting to be wrong in my feed reader but not in browser X 09:35:27 anne, what has doctype to do with it :) 09:35:36 nm that 09:35:39 except for determining ‘standards’ or quirks mode in IE 09:35:54 I rather have the content as user than some error in my face because the author just pressed publish and walked away. 09:36:04 I understand that 09:36:06 Or didn't check in all user agents... 09:36:10 one sec 09:36:18 (Which happens, I posted samples of that to my site.) 09:36:35 Not just in Internet Explorer... 09:38:37 IE doesn’t understand XHTML, so there’s no user agents on the web which don’t at least have a decent understanding of XML 09:39:12 ? 09:39:50 if you author XML, processed by an XML parser, then you should never be presented with a page that’s unreadable because the author didn’t verify the XML-well-formedness 09:40:05 because the author’ll notice that his page is broken immediately 09:40:38 or of course, really because his CMS ran it through a server-side XML parser to test the well-formedness and complains if it isn’t 09:42:34 anyway, if you really want graceful error degradation, use HTML instead of XHTML. If you care about the same in feeds, well honestly, just use an XML parser and let the users complain to the author’s website to fix it :). 09:42:55 I’ve done so to a site that newly had an XML feed implemented, and that worked just fine. 09:42:57 I also care about it on mobile phones. 09:43:26 I also think the character encoding issue would have had to be fixed by now in order for that to be feasible. But it isn't... 09:43:31 I don’t think there’ll be documents that are authored on a mobile phone 09:43:34 hasather has joined #html-wg 09:43:44 Also, I think ease of authoring and users first demands graceful error handling. 09:43:59 Grauw, you obviously don't work for the same company as I do 09:44:08 If the desktop browsers are all strictly validating, and they don’t use some different ‘profile’ or something but just the same content, then they should be authored correctly even if some phones don’t have a proper XML parser 09:44:40 I have worked with a lot of XML technologies though, and also on the support side of that. 09:44:46 We are encountering those problems daily and are currently using heuristics (last I heard) to determine whether or not application/xhtml+xml can be processed as XML... 09:44:56 Backbase processes all documents as XML, and the worst we get as support questions is like 09:45:10 ‘why doesn’t   work’ and we tell them to use ‘ ’ and they’re happy. 09:45:44 I don’t see the need for those heuristics 09:45:55 you are planning, huh :) 09:46:40 Yeah, next semester I'll be working on XML2 as part of my university research project for my Bachelor degree. 09:46:50 or XML5, haven't decided on a name yet 09:47:12 oh, not another naming debate ;-) 09:47:28 I think I could say I probably have more experience with XML technologies than you do, given that Backbase is based on XML, and your work mainly concerns HTML :) 09:47:49 Lachy, just between me and my supervisor at the uni this time... 09:48:16 Grauw, how do you know what my work concerns? 09:48:43 But "XML technologies" sure... 09:48:43 I don’t know, you started the ‘you obviously don’t work for the same company as I do’ path :) 09:48:44 anne: my supervisor first favored "Web Applications 1.0" but later agreed to putting "HTML5" in the title 09:49:16 Grauw, I was just indicating that you can't know the problems we face with mobile content. 09:49:58 anne: do you mean the success story of XML for mobiles is breaking XML? :-) 09:49:58 well I know of a lot of XML-related problems because Backbase is actually one of the few web technologies that uses XML 09:50:08 hsivonen, sort of :) 09:50:36 and we don’t get many of them 09:51:22 writing correct XML is actually extremely simple compared to writing correct HTML :) 09:51:44 most people who don’t get it at first do get it soon thereafter 09:52:36 That's good. I don't plan to change how you have to write XML. 09:52:47 as for Opera, given that they have a fairly wide deployment, they are likely a tested platform for many mobile web sites (as they really test against platforms anyway), and it would be nice if they stood ground with regard to XML validity 09:53:12 XML validity? 09:53:13 hah 09:53:18 well-formedness 09:53:26 you get what I mean 09:53:29 You mean namespace-well-formedness? 09:53:48 As I said, we tried and failed. 09:53:56 I don’t think I have ever heard of namespace-well-formedness so far 09:54:17 Maybe Opera gave up too soon :) 09:54:29 is well-formed but not namespace-well-formed 09:54:56 You can speculate all you wish, but reality is what matters here. 09:55:10 Oh, its "namespace well-formedness" 09:55:27 See http://www.w3.org/TR/xml-names/#ProcessorConformance 09:55:28 Namespace well-formedness then, yes 09:56:29 the problem why there is invalid XML in the first place is because UAs give in to pressure like Opera does 09:56:38 and many, many feed readers 09:57:08 The problem is that people are not perfect. 09:57:13 And make imperfect products. 09:57:30 And we have to deal with that situation and not just pretend it doesn't exist. 09:57:31 they seem to have no problem with well-formedness when creating a Java program 09:57:44 So I don’t buy into the argument that people can’t help doing it wrong 09:57:54 People have lots of problems with different C compilers every day... 09:57:54 or that doing it right is so hard that it’s impossible 09:58:07 that’s a very different issue 09:58:09 if there's some pressure point where I wish Opera had stood firm, it's that I think all browser vendors should have refused to implement XML 1.1 09:58:12 I don't know enough about Java. 09:58:27 but it would be great if C compilers would agree on one language 09:58:41 hsivonen, I think I'll fold in all the good features from XML 1.1 into XML n 09:58:59 XML 1.1 is XML 1.0 plus a wider unicode range, right? 09:59:16 Plus at least one incompatible change... 09:59:35 wider unicode range for element and attributes names btw 09:59:39 yes 09:59:51 the incompatible change being (if it’s easy to describe)? 09:59:53 Grauw: XML 1.1 allows a different arbitrary range of characters (yes, wider) in element and attribute names 10:00:00 Grauw, the spec points them out 10:00:11 some characters are no longer allowed in some production 10:00:13 and some others are 10:00:19 aha 10:00:36 well that’s weird, that they exclude characters that used to be allowed before 10:00:57 the path to crazy implementation cost and interop breakage is paved with i18n political correctness and IBM mainframe compat 10:01:11 XML 1.1 is a classic example of versioning done wrong 10:01:13 unless they were characters that could not actually be used in a regular document 10:01:34 anyway, I need to go :) 10:01:38 (again!) 10:01:44 see you later 10:01:44 heh 10:01:49 bye 10:01:58 http://www.w3.org/TR/xml11/#sec-xml11 10:04:29 The main problem is the control character nonsense. 10:05:05 anne: what exactly is the nonsense in your opinion_ 10:05:06 ? 10:05:35 That you need to use character references and such... 10:06:09 I don't think those changes make much of a problem though... Just allow everything and require #0 to be translated to #FFFD 10:06:18 #x0 to #xFFFD 10:07:08 So new parsers can just ignore the whole thing and continue... 10:08:09 anne: would you allow #xFFFF? 10:08:41 everything that should not be allowed for some good reason will be translated into #xFFFD during the input stream phase I suppose 10:08:49 anne: would #x0 be the only code point that you would not allow in the infoset? 10:08:55 I'm obviously no expert in that 10:13:00 hsivonen, it seems that's what HTML5 does 10:13:19 yes. 10:13:51 in retrospect, I think it was a very bad idea for XML to arbitrarily limit the lexical space of identifiers 10:13:57 Although HTML5 should probably deal with some characters such as those from windows-1252 10:14:11 but gotta run to an iki.fi meeting to lobby for a Jabber server 10:14:19 bye 10:35:12 ROBOd has joined #html-wg 10:43:02 edas has joined #html-wg 10:53:20 gavin has joined #html-wg 13:01:07 gavin has joined #html-wg 13:33:41 erik has joined #html-wg 13:35:00 erik has joined #html-wg 13:36:11 marcos___ has joined #html-wg 13:49:42 h3h has joined #html-wg 14:29:14 Shunsuke has joined #html-wg 15:08:42 gavin has joined #html-wg 15:12:48 Grauw has joined #html-wg 15:53:41 edas has joined #html-wg 15:58:39 h3h has joined #html-wg 16:13:25 sbuluf has joined #html-wg 16:15:24 hasather has left #html-wg 16:16:27 cwahlers has joined #html-wg 16:52:09 st has joined #html-wg 17:00:57 dbaron has joined #html-wg 17:16:00 gavin has joined #html-wg 18:08:45 edas has joined #html-wg 19:22:52 gavin has joined #html-wg 19:55:18 hasather has joined #html-wg 20:00:46 edas has joined #html-wg 20:28:47 h3h_ has joined #html-wg 20:39:40 hasather has joined #html-wg 21:30:20 gavin has joined #html-wg 23:09:12 hasather has left #html-wg 23:25:12 Zeros has joined #html-wg 23:38:15 gavin has joined #html-wg