Like 'FreakinSyco' says you can hover your mouse over the drop-down-list of options and press the delete button. This works for google search too, if you want to remove any search terms that, er, people shouldn't see.
The members who didn't decide on technical grounds are at fault, but the ISO are at fault too for allowing the Fast Track process. Several countries submitted contradictions at the beginning of this and the ISO could have stopped it there. They continued and gave the mammoth task to National Bodies. It's the ISOs fault too.
Oh and just to clarify, I'm not saying that people are trying to hunt anyone down, or that there would be any "disgusting or threatening" communications (I have no reason to think that and I certainly people haven't been behaving that way).
The long answer is that if I post the contact then it will get out of my control and it's likely that the Microsoft person could get disgusting or threatening emails which, quite honestly, I don't want. As much as I find this Microsoft persons' behaviour as quite repugnant I'm going via the official channels. If I get a satisfactory result via that then I'll be happy. As of yet however I have not received anything that would constitute a sincere apology.
In the meantime, I'm asking everyone this favour, I'm the guy involved in this and these are my wishes (feel free to email me on anything at holloway.co.nz if anyone doesn't think that this account is me): please don't hunt this Microsoft person down. I'm on-top of this one, I assure you. I won't let this behaviour go without a response and if I don't get a satisfactory result here I am considering forwarding these details to the European Commission investigations into OOXML (if they don't already know).
Hi ozbird,
I'm not a Standards NZ representative. I am part of the NZ Open Source Society (NZOSS) and a techy on Docvert. I am part of the advisory group formed by Standards NZ for this process but like all others in the group I'm not paid and I'm basically an independent who gets invited to meetings every so often to debate OOXML, and stuff like that.
Not that it's inventive in the slightest but according to the WayBackMachine I posted this back in May 2001,
"Misspelling and synonyms
A good webserver should catch misspellings or synonyms - taking you to the appropriate content or offering a list of near matches (instead of a common 404). Above I used/employment (of a bad URL) but one should catch requests for/employment. Similarly, I don't know of any site's URL structure that isn't annoyingly brittle... where a/job/hamilton will work but/jobs/hamilton will not.
Providing this feature doesn't mean manually considering all possible synonyms. There are dictionaries and thesaurus's available (mod_thesaurus?) so - upon a 404 - the server could return a list of near spellings and near meanings."
- Designing URLs
Well obviously you should provide schemas as well, so basically the question is how to do you make sure that the document and the schema are kept in sync, yes?
So it seems that it's a publishing cycle question. You should have a source document with placeholders that some later process replaces with code snippets. Your schemas could have foreign nodes that denote placeholder Ids, for to map them up.
You could use Docvert which lets you make XML Pipelines from content and build plugins and conversion stages, that way you could replace placeholders from any of your schemas. It generates HTML and DocBook so you could then convert that to PDF or whatever.
Ah, yes I was a bit unclear. My point was that there's no technical reason for propagating this bug into new documents. It's good to preserve expected but buggy behaviour in old documents (as OpenFormula does, and OOXML will presumably do when those flags are defined).
It would be great if ODF could benefit from this too and -- as you say -- keeping quirks in a separate XML namespace would help this.
This is starting to sound like the French and New Zealand opinion of harmonizing the two formats (which even Microsoft developers have told me is quite possible, see my meeting notes from Standards New Zealand.
Well, how about the propagation of historical bugs?
Within OOXML they have ways of dealing with some historical bugs (eg, autoSpaceLikeWord95). When a future revision of OOXML defines what autoSpaceLikeWord95 means then OOXML implementors will be able to distinguish bugs from how it should be.
However this technique is used selectively within OOXML, for example take the 1900 leap year bug, or the 35+ bugs in spreadsheet formulas.
ODF 1.2 with OpenFormula has an approach of adding additional flags to be compatible with historical bugs while preventing bug propagation in future documents. See this blog post for more
Microsoft have stated that the 1900 bug in Microsoft Excel was done to emulate a bug in Lotus 123. Correct blame is good, but we should still squash this bug now.
There's no technical reason for propagating this bug, and we should not allow this in an ISO standard.
Nothing in the XML specs says that any actual document is hosted at the URI. It's a mechanism to specify a globally unique identifier. It's an identifer, not a promise to host a document. Some folks host the DTD document at the URI, but there's no requirement to do that.
For the XMLNS yes, but for the DOCTYPE no. The system resource field in a doctype does refer to a system path or a url, and there's no way to resolve non-default XML entities. You could assume HTML entities, as most RSS parsers do.
While I'm sure not every RSS client uses a high-quality XML implementation, it seems clearly true that every RSS client is an XML processor. RSS is an XML format. So an RSS client is, um, processing XML...
They're processing tags, but anything that touches XML doesn't qualify as an "XML processor" (as per the W3C definition). An XML processor must fail when faced with an unresolvable entity or invalid XML. Many RSS parsers such as the Universal Feed Parser do not read RSS as XML but through string manipulation, regexs, and complex parsing logic. They're taking a leaf from HTML parsers and doing the best they can with the given document in order to be more robust. They tend to dynamically replace entities through string replacement rather than resolving external DTDs.
This is backed up by Chris Finke of Netscape, who said..
Theoretically, RSS readers load this file when parsing an RSS 0.91 feed. However, In practice, most readers (including those built into Firefox and Internet Explorer) either just ignore the file or load their own cached copy.
The unavailability of this file had the effect of causing certain feed readers - Microsoft's Live.com RSS gadget, for one - to refuse to display RSS 0.91 feeds.
So, there are some RSS parsers that resolve DTDs, and some that don't. The ones that want to parse a DTD to resolve entities should cache it, as I was saying.
Yes, you're right, that's the standard way of caching them locally. I'm not sure that all RSS clients are XML processors though.
HTML clients (browsers) don't go requesting the HTML dtd, and so it could be said that the RSS client shouldn't either. For RSS clients though they're more pure in that they take the DTDs definition of entities literally so we do need to access the DTD.
But you'd expect clients to cache them, using XML catalogs as you say. They should be packaged with the standard DTDs, a default DTD with all the HTML entities, and only check for updates occasionally without requiring it.
Interpretations of Alanis's Song "Ironic",
1) She didn't know the meaning of the word and the song's examples prove it.
2) She did know the meaning of the word and she consistently came up with examples that weren't ironic. Naming the song ironic would then be quite ironic.
There's no real evidence either way. She said in an interview that it's (2) so I guess it's all to do with whether you believe her.
Is it invulnerable because the file they happened to choose is restricted (c:\boot.ini) or because the browser is now smart enough not to give javascript focus to file upload fields?
If so then it's still vulnerable because they'll release a patch to stop hackers from uploading user files, like those with predictable filenames. It seems wrong to say that IE+Vista aren't vulnerable when the IE bug still exists.
(of course if IE7 prevents giving focus to the upload field then I'm wrong -- but I don't think that's the case. The same bug exists in IE7 on Vista)
PDF and Postscript lack the structure needed to edit files (headings, paragraphs). So just so you all know, this would retain MSWord as the source format. Converting to ODF however would mean an open standard source format.
Slashdot Mirror
Like 'FreakinSyco' says you can hover your mouse over the drop-down-list of options and press the delete button. This works for google search too, if you want to remove any search terms that, er, people shouldn't see.
Oh, interesting, I didn't know that. Thanks for the tip. I'll choose TTF equivalents in the future.
I agree. We're back to where we were a year ago only now with a lot more awareness of the office monopoly and how much money is wasted.
Here are two reports on OOXML that I recently released, one (PDF, 0.9MB) and two (PDF, 0.8MB).
The camps are those who benefit from the Microsoft Office monopoly vs those who don't. It's not hate. It's economics.
The members who didn't decide on technical grounds are at fault, but the ISO are at fault too for allowing the Fast Track process. Several countries submitted contradictions at the beginning of this and the ISO could have stopped it there. They continued and gave the mammoth task to National Bodies. It's the ISOs fault too.
Oh and just to clarify, I'm not saying that people are trying to hunt anyone down, or that there would be any "disgusting or threatening" communications (I have no reason to think that and I certainly people haven't been behaving that way).
Heh, well the short answer is "no".
The long answer is that if I post the contact then it will get out of my control and it's likely that the Microsoft person could get disgusting or threatening emails which, quite honestly, I don't want. As much as I find this Microsoft persons' behaviour as quite repugnant I'm going via the official channels. If I get a satisfactory result via that then I'll be happy. As of yet however I have not received anything that would constitute a sincere apology.
In the meantime, I'm asking everyone this favour, I'm the guy involved in this and these are my wishes (feel free to email me on anything at holloway.co.nz if anyone doesn't think that this account is me): please don't hunt this Microsoft person down. I'm on-top of this one, I assure you. I won't let this behaviour go without a response and if I don't get a satisfactory result here I am considering forwarding these details to the European Commission investigations into OOXML (if they don't already know).
Hi ozbird, I'm not a Standards NZ representative. I am part of the NZ Open Source Society (NZOSS) and a techy on Docvert. I am part of the advisory group formed by Standards NZ for this process but like all others in the group I'm not paid and I'm basically an independent who gets invited to meetings every so often to debate OOXML, and stuff like that.
Good point -- IE doesn't display custom 404s unless the response body is over a certain length.
The one video that sums up this patent deal is this one by Eben Moglen
OfficeSweet.
So it seems that it's a publishing cycle question. You should have a source document with placeholders that some later process replaces with code snippets. Your schemas could have foreign nodes that denote placeholder Ids, for to map them up.
You could use Docvert which lets you make XML Pipelines from content and build plugins and conversion stages, that way you could replace placeholders from any of your schemas. It generates HTML and DocBook so you could then convert that to PDF or whatever.
Presumably you wouldn't have a problem with that :)
Yes, you're correct, and here's a fuller description of the backwards compatibility claims.
It would be great if ODF could benefit from this too and -- as you say -- keeping quirks in a separate XML namespace would help this.
This is starting to sound like the French and New Zealand opinion of harmonizing the two formats (which even Microsoft developers have told me is quite possible, see my meeting notes from Standards New Zealand.
"objectively horrible" eh? ;)
Well, how about the propagation of historical bugs?
Within OOXML they have ways of dealing with some historical bugs (eg, autoSpaceLikeWord95). When a future revision of OOXML defines what autoSpaceLikeWord95 means then OOXML implementors will be able to distinguish bugs from how it should be.
However this technique is used selectively within OOXML, for example take the 1900 leap year bug, or the 35+ bugs in spreadsheet formulas.
ODF 1.2 with OpenFormula has an approach of adding additional flags to be compatible with historical bugs while preventing bug propagation in future documents. See this blog post for more
Microsoft have stated that the 1900 bug in Microsoft Excel was done to emulate a bug in Lotus 123. Correct blame is good, but we should still squash this bug now.
There's no technical reason for propagating this bug, and we should not allow this in an ISO standard.
Not really -- The "no"s have to be technical but the "yes" doesn't need any justification.
Yes, you're right, that's the standard way of caching them locally. I'm not sure that all RSS clients are XML processors though.
HTML clients (browsers) don't go requesting the HTML dtd, and so it could be said that the RSS client shouldn't either. For RSS clients though they're more pure in that they take the DTDs definition of entities literally so we do need to access the DTD.
But you'd expect clients to cache them, using XML catalogs as you say. They should be packaged with the standard DTDs, a default DTD with all the HTML entities, and only check for updates occasionally without requiring it.
Interpretations of Alanis's Song "Ironic", 1) She didn't know the meaning of the word and the song's examples prove it. 2) She did know the meaning of the word and she consistently came up with examples that weren't ironic. Naming the song ironic would then be quite ironic. There's no real evidence either way. She said in an interview that it's (2) so I guess it's all to do with whether you believe her.
Is it invulnerable because the file they happened to choose is restricted (c:\boot.ini) or because the browser is now smart enough not to give javascript focus to file upload fields?
If so then it's still vulnerable because they'll release a patch to stop hackers from uploading user files, like those with predictable filenames. It seems wrong to say that IE+Vista aren't vulnerable when the IE bug still exists.
(of course if IE7 prevents giving focus to the upload field then I'm wrong -- but I don't think that's the case. The same bug exists in IE7 on Vista)
Yeah it was a good effort by everyone :)
PDF and Postscript lack the structure needed to edit files (headings, paragraphs). So just so you all know, this would retain MSWord as the source format. Converting to ODF however would mean an open standard source format.
My software is working on the presentation engine part -- from MSWord/OpenDocument to HTML or DocBook or RSS. It's called Docvert.