Proposed Disposition
We agree that, as defined, the CEILING function does not follow the generally accepted practice for negative
numbers. However, in order to maintain compatibility with the corpus of existing documents that use the
CEILING function and rely on its current behaviour, no change will be made to Part 4, Â3.17.7.33 page 2,559.
(but they say that one was fixed in the final spec after the BRM)
Luckily for us, nobody would dare to try push through such a subversive standard;-)
.. so I doubt whether the words "require" (gp) and "mandated" (pp) apply, without a link.
PDF was mentioned in this interesting, now 5 years old, advisory Valoris report (as PDF, of course;-)).
I can really recommend this as it shows how much strife and conflict we've all had the past 5 years, and how much is at stake:-/
Apparently, the next version of the European Interoperability Framework is in the making, and these months you can post public comments. So if you think UOF should be adopted by European governments, now's your chance:-)
The draft document is at this location, and probably chapter 8 is most relevant for us Slashdotters. Note MS = Member States and PEGSCO = IDABC management committee (nothing to do with SCO).
p. 425 "
Politicians use the term "creeping normalcy" to refer to such slow trends concealed within noisy fluctuations. If the economy, schools, traffic congestion, or anything else is deteriorating only slowly, it's difficult to recognize that each successive year is on the average slightly worse than the year before, so one's baseline standard for what constitutes "normalcy" shifts gradually and imperceptibly. It may take a few decades of a long sequence of such slight year-to-year changes before people realize, with a jolt, that conditions used to be much better several decades ago, and that what is accepted as normalcy has crept downwards.
"
Jared Diamond, "Collapse", ch. 14 "Why do some societies make disastrous decisions?", p. 425
The reporter was quite impressed, I remember that. But he did'nt feel it as a spiritual experience.
I have no idea if what you propose is possible: maybe, people's brains are wired sufficiently differently to make this "implanting a thought pattern" very difficult, unless it's a very crude pattern. Plus, the "please put on this special motorcycle helmet" would give the plan away;-)
I'm joking. Linux has developed into an ecosystem, not just a single product, so why reduce it to that?
The people using Linux on their mobile phones, and those using it on their research supercomputers might disagree with your idea of optimizing it for the desktop only.
As XML has no native support for binary objects such as images, [OLE] objects, or other media types, and because uncompressed XML files can get very large, OpenDocument uses a package file to store the XML content of a document together with its associated binary data, and to optionally compress the XML content. This package is a standard Zip file, whose structure is discussed below.
Information about the files contained in the package is stored in an XML file called the manifest file. The manifest file is always stored at the pathname META-INF/manifest.xml. The main pieces of information stored in the manifest are as follows:
A list of all of the files in the package.
The media type of each file in the package.
If a file stored in the package is encrypted, the information required to decrypt the file is stored in the manifest.
Try unzip a.odp file for example.
The manifest entries (<manifest:file-entry>) have an attribute manifest:media-type which contains the MIME-type of the blob (e.g. a picture of a cute kitten) and its location (usually in the Pictures directory).
So, as long as only open-standard MIME-types are used, I don't see why this is a problem for interoperability. Anyone can implement JPEG, GIF and PNG, for example. Maybe not in the USA but that will hopefully soon be harmonized with the more enlightened EU patent model, now that they saw the light, if I understand TEC plan (pdf) correctly;-) (hint: I probably don't;-))
Note that ODF (the stack to the right) is already a large standard, and the two standards are supposed to cover exactly the same thing. Which would you prefer to implement?
O RLY? My personal thought about this is that you're setting up ENEMY straw-men, and then eloquently DESTROY them.
Lemme give you an anecdote: fifteen years ago, I received a proprietary program that I used in a research project. It was written for a slightly different architecture, but because I found out that I only had to MODIFY a few low-level C I/O routines in the SOURCE, we could use it on our SGI Indy & spent about a CPU-year using that program to do our calculations. Great success!
The point is, that having access to the source, but not explicitly the right to modify it to suit whatever workstation you have available for your work, is often useless, both in an open source context or in an (effectively) closed-source context.
So, if I understand correctly, if this particular program had been licensed under the Ms-RL license I would have had the same freedom (and then some, because it's apparently an open source license), but if it had been licensed under the Ms-LRL license, it would have been absolutely useless to me, because I wouldn't have access to the same computing platform as where the code had been written, and I would have been forbidden to modify it.
Ms-RL good, Ms-LRL *BAD*. I find this choice of license names by Microsoft very confusing. Especially if you contrast it with the GNU GPL and GNU LGPL (LGPL Less restricted than GPL).
Also, the FSF claims that these Microsoft licenses are incompatible with the GPL (which was written much earlier), so I think Microsoft did this on purpose.
If you're interested, there was a discussion on this on the LWN site last year.
As to the rest of your post, I don't actually understand what you mean, sorry.
And I personally think we humans will leave this rock before overpopulation is an issue.
Who, all of us? or do you mean "we, happy few vegan lesbian Pygmy Mars colonists" when you say "we, humans"? (You insensitive clod)
Somehow, I don't believe they're going to pack a year worth of hamburgers and a few cows along on the trip:-)
I've read that sometimes, problems such as overpopulation and changing environment cannot be percieved ahead of time because their discussion clashes with cultural values, and many past civilizations preferred hanging on to those cultural values, and proudly died out as a result.
So be it. When Rome collapsed, not everyone living there was killed. But people turned to different priorities in their life. The Forum Romanum was re-discovered what, about a hundred years ago? And completely intact, because it was buried under meters of soil, because the surviving Romans used that area to herd their cows for 1400 years (or so I'm told; lookup "Campo Vaccino").
I hope that when we're long dead, people find some lessons of value in the 20th century's western civilization. But I don't think "we ARE nature" and "population control will happen one way or the other" are lessons they'll learn from *us*, particularly.
When you said "we humans will leave this rock" I think you had this picture of an open system in mind. While this is technically so, I don't think we have the technology and drive yet to do what is necessary to colonize space(*) (for example, would you get your legs amputated if it saved payload for the trip?). So, for all intents and purposes, we have a closed system. Then, we'd better make it work in "steady state", or die off.
(*)Read: "Stark", by Ben Elton, for how *NOT* to do it!
On the other hand, I like your expression
On the contrary, this is a universe that peoples.
Autopoiesis? Surely with 9 billion reasonably educated people someone would find a new equilibrium point. With 9 billion starving people who can only think about where they're going to get their next week's meal from, not so much.
The European Union Public License, which is similar to GPLv2 to my untrained eye, is available in lots of languages, including "Portuguese Portuguese":-)
Spreadsheet formulas were apparently added with much effort in ODF 1.2 (OpenFormula, draft).
I think I get what you mean with irregular tables.
Paragraph 8.1 says
Table rows may be empty, and different rows might contain a different number of table cells.
This is not an error, but applications might resolve this in different ways. Spreadsheet
applications typically operate on large tables that have a fixed application dependent row and
column number, but may have an unused area. Only the used area of the table is saved in files.
If this is insufficient to specify an "irregular table", e.g. to nicely layout its outer border, you'll have to be more specific..
I don't know what you mean with ink.
BTW, there was an effort to include Microsoft Office features into ODF, but Sun explicitly rejected it, saying that ODF should not go beyond StarOffice/OO.o features.
Wow.. that's rich..
Even if Sun played nasty in OASIS, which I can't comment on because I'm an outsider, don't you think that a lot of new companies suddenly could have joined the OASIS Office committee who all miraculously voted in favour of these Microsoft Office features? I'm sure a way would have been found, and it would have been cheaper than lobbying 87 nations. Without the approval vote of Kazakhstan, CÃte d'Ivoire, and Trinidad and Tobago OOXML wouldn't have passed:-(
BTW: why does it say "Status: deleted" (with an icon of a garbage can) on the ISO 29500 page?
I must be hallucinating.
ODF also lacks the ability to embed OLE objects as XML. ODF only stores OLE objects as binary blobs, while Microsoft OFfice allows OLE object to be stored as XML is possible (and binary blobs if not). This makes it possible to traverse a hierarchy of embedded OLE objects using XML parsing.
I don't understand this point: if it's a blob, all it needs is a descriptor (such as SMIL), and if it's not a blob, why isn't it in the standard, or referred to with its own international standard?
ISO OOXML uses a single format for spreadsheet dates (the ISO standard), while ODF uses 3 different date formats.
Um.. from ECMA's disposition of comments, about OOXML's 1900- and 1904-based dates:
Regarding the requests that we adopt a single date base, we do not see this as a viable option given the corpus
of existing binary documents requiring support for the existing 1900 and 1904 date bases.
I think I'll stop answering your points now.. I'm tired.
NIA's Steering Committee was NOT called upon to review, and possibly override, the working committee's technical decision - it does not have the authority to do so. It was, however, involved in a decision as to whether or not the voting procedure at ISO correctly adhered to the formal criteria. Because the Steering Committee's decision did not relate to any technical issues or the content of the standard itself, but dealt solely with the formalities of the JTC 1 "fast track" procedure, i.e. adherence to procedural rules in the standardization process, DIN felt it was necessary to take a position on this matter. This is the reason the DIN staff member participated in the voting procedure and did not abstain, as is the rule in questions of technical content.
On 27 March 2008 the NIA Steering Committee members who were entitled to vote did NOT vote on approval or non-approval of ISO/IEC DIS 29500 as an International Standard, but SOLELY on the regularity of the voting procedure itself. With a majority of 7 to 6, and 7 abstentions, the Steering Committee deemed the procedure as being in conformity with the rules, and thus had no reason to override the working committee's "YES" vote. Had the majority of the Steering Committee been convinced that the procedures for developing and voting on ISO/IEC DIS 29500 were in any way irregular, the German vote would have been changed to "ABSTAIN".
I read this to say, that the technical question "is Germany in favour of this standard?" degenerated to a vote on technicalities of the voting procedure, this gave a "tie" (6-6, 7 abstentions), and then, disregarding the usual protocol, the DIN representative gave themselves a vote and broke the tie in favour of standardizing OOXML on the fast track anyway, whereas the only effect of a no vote would have been, that it would have to be standardized on the normal track.
Would you trust a standard for food safety, if it was decided upon in this way?
WHAT features? Link please? I keep hearing this but it's all noise and no signal.
Evidently if the committee that drafted ODF missed features essential for text processing, or even necessary for interoperability with the much-used old MS.doc formats, it might be a good thing to add those features. So, tell me what are they?
autoSpaceLikeWord95 wasn't documented in the original OOXML document; IIRC it was clarified for the first time by ECMA in their Disposition of Comments from Januari 2008 (response 34, page 223):
Agreed; we will fully define the information necessary to implement each compatibility setting which was not previously completely described....
Note the future tense.
Maybe, Slashdotters are just slow readers and haven't finished reading the 2293 pages of the Disposition of Comments in the past 3 months:-)
Besides, I'm not sure if it is actually a publically readable document: the version on the SC34 website (document #980) is locked and I'm not authorized to download it: DIS29500-2008-002.pdf
There's some meta-info about the document by Rick Jelliffe here:
Interestingly, Jelliffe wrote:
There is a small chunk of comments that are out of scope (typically concerning IPR or procedural comments.) There is a small chunk which the Editor has decided are issues for the maintenance phase, not the fast-track process: these are typically how comments like âoeODF has feature X, why doesnâ(TM)t OOXML support it?â There is another chunk of issues where the Editor disagrees with the substance of the comment, but wants to address the issue by adding clarifying or helpful text to the specification: for example, the issue of bitmasks is handled by giving examplars of how to handle them in XSD, RELAX NG, Schematron, DTLL and XSLT.. And finally, another chunk where the Editor disagrees, and gives the rationale for the disagreement. These are typically where the comments cross ECMAâ(TM)s line in the sand: that no currently valid OOXML document should become invalid.
So I say: go UKUUG! Sue their pants off! (and I'm not even a Brit).
You pull up sour crude, heavy crude, ultra-heavy crude, or even bitumen, and you've got a big refining task ahead of you. You cook oil out of keragenous rock like shale, and you're doing even more organic chemistry. Ultimately, you can make oil simply from CO or CO2, plus water for the H2, plus energy, via Fisher-Tropsch or Sabatier synthesis. In short, for oil to be able to *physically* run out, you need "peak energy" to occur.
Yes, but as ESR pointed out long ago, you and your competitor are most likely not in the business of selling software.
There are actually only very few companies in the world who sell software -- for all the rest, paying someone to fix a software bug is a cost just like having someone come over to repair your central heating system:
Your job may yield the central heating mechanic enough profit to buy better equipment, so he becomes more competitive, and repairs your competitor's central heating system for less:
better wait until one of your competitors' heating systems break down too, and then get yours repaired afterwards for less money!
P.S. I recommend that ESR essay "The Magic Cauldron", it's fun to read, and even on-topic.
Slashdot Mirror
Which Unicode, UTF-16 or UTF-8?
</nitpick>
Rob Weir's blog post on YEARFRAC()
or faulty mathematical functions:
(but they say that one was fixed in the final spec after the BRM)
Luckily for us, nobody would dare to try push through such a subversive standard ;-)
PDF was mentioned in this interesting, now 5 years old, advisory Valoris report (as PDF, of course ;-)).
I can really recommend this as it shows how much strife and conflict we've all had the past 5 years, and how much is at stake :-/
Apparently, the next version of the European Interoperability Framework is in the making, and these months you can post public comments. So if you think UOF should be adopted by European governments, now's your chance :-)
The draft document is at this location, and probably chapter 8 is most relevant for us Slashdotters. Note MS = Member States and PEGSCO = IDABC management committee (nothing to do with SCO).
How cool would it be to have a fusion-reactor-driven zeppelin that replenishes its own Helium?
OTOH, I'd imagine people would object to the possibility of a fusion reactor dropping on their house in case of an accident.
Great idea! Because if the average user feels this in his wallet, the spam problem finally gets addressed and solved as well.
Do you mean like Temporal lobe tickling and spirituality TV program (in Dutch)?
The reporter was quite impressed, I remember that. But he did'nt feel it as a spiritual experience.
I have no idea if what you propose is possible: maybe, people's brains are wired sufficiently differently to make this "implanting a thought pattern" very difficult, unless it's a very crude pattern. Plus, the "please put on this special motorcycle helmet" would give the plan away ;-)
Good idea! When will you have it ready for us? :-)
I'm joking. Linux has developed into an ecosystem, not just a single product, so why reduce it to that?
The people using Linux on their mobile phones, and those using it on their research supercomputers might disagree with your idea of optimizing it for the desktop only.
There's room for everyone.
A while ago I read this article: LWN article about ext4 fs
and your comment reminded me of it. I think it's very impressive that some people can think far ahead.
Try unzip a .odp file for example.
The manifest entries (<manifest:file-entry>) have an attribute manifest:media-type which contains the MIME-type of the blob (e.g. a picture of a cute kitten) and its location (usually in the Pictures directory).
So, as long as only open-standard MIME-types are used, I don't see why this is a problem for interoperability. Anyone can implement JPEG, GIF and PNG, for example. Maybe not in the USA but that will hopefully soon be harmonized with the more enlightened EU patent model, now that they saw the light, if I understand TEC plan (pdf) correctly ;-) (hint: I probably don't ;-))
Note that ODF (the stack to the right) is already a large standard, and the two standards are supposed to cover exactly the same thing. Which would you prefer to implement?
Lemme give you an anecdote: fifteen years ago, I received a proprietary program that I used in a research project. It was written for a slightly different architecture, but because I found out that I only had to MODIFY a few low-level C I/O routines in the SOURCE, we could use it on our SGI Indy & spent about a CPU-year using that program to do our calculations. Great success!
The point is, that having access to the source, but not explicitly the right to modify it to suit whatever workstation you have available for your work, is often useless, both in an open source context or in an (effectively) closed-source context.
So, if I understand correctly, if this particular program had been licensed under the Ms-RL license I would have had the same freedom (and then some, because it's apparently an open source license), but if it had been licensed under the Ms-LRL license, it would have been absolutely useless to me, because I wouldn't have access to the same computing platform as where the code had been written, and I would have been forbidden to modify it.
Ms-RL good, Ms-LRL *BAD*. I find this choice of license names by Microsoft very confusing. Especially if you contrast it with the GNU GPL and GNU LGPL (LGPL Less restricted than GPL).
Also, the FSF claims that these Microsoft licenses are incompatible with the GPL (which was written much earlier), so I think Microsoft did this on purpose.
If you're interested, there was a discussion on this on the LWN site last year.
As to the rest of your post, I don't actually understand what you mean, sorry.
Hey, at least it's not a Diet of Worms..
Somehow, I don't believe they're going to pack a year worth of hamburgers and a few cows along on the trip :-)
I've read that sometimes, problems such as overpopulation and changing environment cannot be percieved ahead of time because their discussion clashes with cultural values, and many past civilizations preferred hanging on to those cultural values, and proudly died out as a result.
So be it. When Rome collapsed, not everyone living there was killed. But people turned to different priorities in their life. The Forum Romanum was re-discovered what, about a hundred years ago? And completely intact, because it was buried under meters of soil, because the surviving Romans used that area to herd their cows for 1400 years (or so I'm told; lookup "Campo Vaccino").
I hope that when we're long dead, people find some lessons of value in the 20th century's western civilization. But I don't think "we ARE nature" and "population control will happen one way or the other" are lessons they'll learn from *us*, particularly.
When you said "we humans will leave this rock" I think you had this picture of an open system in mind. While this is technically so, I don't think we have the technology and drive yet to do what is necessary to colonize space(*) (for example, would you get your legs amputated if it saved payload for the trip?). So, for all intents and purposes, we have a closed system. Then, we'd better make it work in "steady state", or die off.
(*)Read: "Stark", by Ben Elton, for how *NOT* to do it!
On the other hand, I like your expression
Autopoiesis? Surely with 9 billion reasonably educated people someone would find a new equilibrium point. With 9 billion starving people who can only think about where they're going to get their next week's meal from, not so much.</long_incoherent_rant>
The European Union Public License, which is similar to GPLv2 to my untrained eye, is available in lots of languages, including "Portuguese Portuguese" :-)
I think I get what you mean with irregular tables. Paragraph 8.1 says
If this is insufficient to specify an "irregular table", e.g. to nicely layout its outer border, you'll have to be more specific..I don't know what you mean with ink.
Wow.. that's rich..Even if Sun played nasty in OASIS, which I can't comment on because I'm an outsider, don't you think that a lot of new companies suddenly could have joined the OASIS Office committee who all miraculously voted in favour of these Microsoft Office features? I'm sure a way would have been found, and it would have been cheaper than lobbying 87 nations. Without the approval vote of Kazakhstan, CÃte d'Ivoire, and Trinidad and Tobago OOXML wouldn't have passed :-(
BTW: why does it say "Status: deleted" (with an icon of a garbage can) on the ISO 29500 page? I must be hallucinating.
I don't understand this point: if it's a blob, all it needs is a descriptor (such as SMIL), and if it's not a blob, why isn't it in the standard, or referred to with its own international standard?ISO OOXML uses a single format for spreadsheet dates (the ISO standard), while ODF uses 3 different date formats.
Um.. from ECMA's disposition of comments, about OOXML's 1900- and 1904-based dates:
I think I'll stop answering your points now.. I'm tired.
From DIN website
I read this to say, that the technical question "is Germany in favour of this standard?" degenerated to a vote on technicalities of the voting procedure, this gave a "tie" (6-6, 7 abstentions), and then, disregarding the usual protocol, the DIN representative gave themselves a vote and broke the tie in favour of standardizing OOXML on the fast track anyway, whereas the only effect of a no vote would have been, that it would have to be standardized on the normal track.
Would you trust a standard for food safety, if it was decided upon in this way?
Evidently if the committee that drafted ODF missed features essential for text processing, or even necessary for interoperability with the much-used old MS .doc formats, it might be a good thing to add those features. So, tell me what are they?
Note the future tense.
Maybe, Slashdotters are just slow readers and haven't finished reading the 2293 pages of the Disposition of Comments in the past 3 months :-)
Besides, I'm not sure if it is actually a publically readable document: the version on the SC34 website (document #980) is locked and I'm not authorized to download it: DIS29500-2008-002.pdf
There's some meta-info about the document by Rick Jelliffe here: Interestingly, Jelliffe wrote:
So I say: go UKUUG! Sue their pants off! (and I'm not even a Brit).
It's about vote packing (OOXML) but also that subverting a standards process is not nice (Rambus).
Dynamite is made of dead cyanobacteria, you insensitive clod!
At least these cyanobacteria seem to be doing photosynthesis which is a Good Thing for us :-).
One word is enough to put a dent in your logic:
EROEI
There are actually only very few companies in the world who sell software -- for all the rest, paying someone to fix a software bug is a cost just like having someone come over to repair your central heating system:
Your job may yield the central heating mechanic enough profit to buy better equipment, so he becomes more competitive, and repairs your competitor's central heating system for less:
better wait until one of your competitors' heating systems break down too, and then get yours repaired afterwards for less money!
P.S. I recommend that ESR essay "The Magic Cauldron", it's fun to read, and even on-topic.