Скоро Новый год, какие есть предложения? лучше думать про новы год чем про приколы сакашвили.

Предлагаю Вам научиться зарабатывать на интернет торгах Форекс.
 Практиковаться можно на демо или центовых счетах, все наглядно п казано в рисунках.
Бесплатные конкурсы. Forex счета любые: USD, RUB, EURO, от 0,01 лота и от 0,1 доллара. Различные потоковые новости, в т.ч. и в программе. Отл чная партнерская программа. Кредитование трейдеров. Создай свой остоянный поток денег. Компания Ринкост - отличные условия для т ейдинга: www.rinkost.ru/partner/fordoc

chicorolrel

Matthew,

Yes, I'm certain that "should" was the intent of the BRM; there was quite a bit of discussion around that exact point. I'm happy that it comes across in the text as well.

Carlos,

I'm not going to give any opinions on the spec until I've talked to my national body about it.

I'm certainly not arguing that ODF was accepted therefore OOXML should be; I agree that's a poor argument. What I'm saying is that any reforms to the process should make it better able to cope with ODF as well as OOXML - which is why I'm not convinced that banning Ecma is the right solution (as well as being difficult in practice).

Inigo

"So, any suggestions as to how to improve the fast-track/PAS process?"

Yes, ban organizations like ECMA, that show a deep lack of respect of standards, standardization and national bodies, throwing to ISO poor edited and not properly reviewed specifications like DIS 29500.

( i don't agree with the argument: because ODF was fast-tracked , any beast that is throwed to ISO must be fast-tracked ... it sound me like the Durusau recent argumentation to approve DIS 29500: because Microsoft is being good and open we must accept *now* this draft )

( i wouldn't compare ODF with DIS 29500, we are talking of a 10th of order of page size, and a properly pre-reviewed specification.. in an open and transparent process , in an open and serious organization: OASIS )

( i know, i'm being extremist, but some people is gaming with our standards, and i, as a final user, don't like that )

  Carlos
   Carlos

Thanks for your explanation

"I'd rather have NBs vote based on the current merits or otherwise of the specification"

I believe that the complain about the +6000 page size has to do with that:

there is no time to guarantee that DIS 29500 has the technical merits to be an ISO standard.

Do you believe that this specification ( what ever it final text is ... because still we don't have a text to review ) has the technical merits to be an ISO standard?

Regarding mpeg audio (mp3) and mpeg2,

It also says "Add a table with a minimal number of reference standard
formats" which to me reads as if they're saying that those are the minimal
number of formats that an implementor should have (eg a MUST).

Do we know that the "should" in this case is control language? It
seems that the words chosen around this mean MUST.

Hi Carlos,

I'm not happy that DIS 29500 is being fast-tracked: I think it's too large and complex to be dealt with effectively through the fast track mechanism. Nor do I think that ODF was suitable for the PAS process. The PAS process, like the fast-track process, means that there is a relatively short time for review and change.

An interesting question is how the fast-track/PAS processes could be altered to prevent more such large specifications being passed through them. One way would be to establish a maximum page count, above which specs wouldn't be eligible. This has the problem that like any fixed metric, it can be gamed. OOXML, for example, has lots of duplication of definitions that bulks out its pagecount, but some would claim that this increases its readability. And for complex topics, it's almost always better to have longer explanations than shorter ones - many of the OOXML dispositions that were accepted added additional text, because they were providing more explicit definitions of features. It would be undesirable to discourage full explanations.

Another method would simply be for national bodies to vote against OOXML on the grounds of its size and unsuitability for fast-tracking. Personally, I'm not in favour of this - I'd rather have NBs vote based on the current merits or otherwise of the specification, rather than the process by which it was submitted. (Note that if a similar approach had been taken for ODF, then that might well have been rejected based on size and time to review; which many people would have considered to be a bad decision)

So, any suggestions as to how to improve the fast-track/PAS process?

Inigo

Hi Inigo

A couple of months ago, you said at http://surguy.net/articles/ooxml-validatio...echnical-review.xml:

"Approximately 300 of the examples are in error - more than 10%. While a certain number of errors is understandable in any large specification, the sheer volume of errors indicates that the specification has not been through a rigorous technical review before becoming an Ecma standard, and therefore may not be suitable for the fast-track process to becoming an ISO standard."

( by the way AFAIK, the text with the corrected examples is still not available to proper review and validation by NBs )

I would like to ask you ... do you still believe that "[DIS 29500] may not be suitable for the fast-track process to becoming an ISO standard" ?

Thank you, and greetings from Argentina ( my national body abstained, due to lack of interest/expertise in XML :-(

     Carlos Martel

Never mind, I found my answer. It isn't a bug after all, according to ECMA-379 Part 5 Clause 9.1.3. PreserveElements and PreserveAttributes are defined to be hints, not requirements. I captured the definitive text in my comment at
http://orcmid.com/blog/2008/02/ooxml-odf-h...1235882653159917547
with lede "Oops! Not a bug"

Did you find out if the compatibility support for preserving attributes of unrecognized extensions was fixed in Office 2007 Service Pack 1? I know there were some other fixes, but I haven't found out how to check on this one.

I mean the problem identified here:
http://odf-converter.sourceforge.net/blog/...-extensibility#c130

and that you had confirmed yourself.

Hi! Nice site!

Very interesting. Very worrying!

Thanks for posting this, Inigo. I was also surprised to see that our standards body, the BSI, was conducting this process in such an open fashion. :)

Thanks.

Please discuss OOXML validation here.