ISO אישרו את OOXML – מה זה אומר על העתיד

לא הצלחתי להבין אם זה רשמי או לא, אבל ISO אישרו כתקן בין-לאומי את DIS29500, הידוע גם בתור Office Open XML. מדובר על פורמט הקבצים שבו מיקרוסופט טוענת שהיא מעבירה קבצים בגרסאות המודרניות של Office. רק לצורך שלמות הקישורים, הדיווח ב-whatsup ו-slashdot.

אני יודע שציבור אנשי התוכנה החופשית כועסים ודואגים, אבל אני חושב שאנשים ממקדים את החשש שלהם בכיוון הלא נכון. הבעיה היא לא DIS29500. הבעיה היא כל השאר.

אני חייב להודות שאני מסתכל על רמת הדיון שהתקיימה בנושא, ואני מקבל תחושות מעורבות. לקרוא את מה שפמלה ג’ונס כותבת על הנושא ב-groklaw יגרום לך לחשוב שכל מי שהצביע או חשב ש-OOXML זה רעיון טוב הוא מושתל של מיקרוסופט. אני חושב שההתייחסות הזו היא הן פרנואידית והן לא מועילה. אף אחד לא אוהב להרגיש שהוא עושה כמיטב יכולתו, ואז לקבל טענות שמישהו משלם לו שוחד.

מה שיותר גרוע, מבחינתי, זה ההתמקדות בבעיות הטכניות שיש ב-DIS29500. אל תבינו אותי לא נכון. יש בתקן הזה המון בעיות טכניות. הסיבה שאני חושב שההתמקדות בהן היא לא נכונה היא שבכל הצעת תקן, וברוב התקנים, יש גם בעיות טכניות. לינגנו נמצאת כרגע בשלב הצעת עבודה על עבודה שכל מטרתה היא לשפר את התקן הישראלי (של מכון התקנים) לגבי עריכת טקסט דו לשונית. האם זה שהתקן הנוכחי (לדעתי, אבל מי שכתב אותו בהחלט הצטרף אליה) לא מספיק טוב אומרת שזה תקן רע? לדעתי לא. תקן לא מספיק טוב הוא עדיין טוב מהעדר מוחלט של תקן, בעיקר בגלל שאנשים כמוני יכולים לבוא ולהציע שיפורים.

וכאן בדיוק הבעיה האמיתית עם OOXML. הבעיה היא לא החלקים הטכניים של התקן. כבר שמעתי נציגים של מיקרוסופט מציינים (ובדקתי – בצדק) בעיות חמורות יותר עם תקן ה-ISO של ODF.הבעיות הבאמת חמורות עם OOXML, בעיות שאמורות היו לפסול אותו על הסף, נמצאות במקום אחר, וככל שאנחנו מתמקדים יותר בבעיות הטכניות כך אנחנו פחות מאירים את הבעיות האחרות.

הבעיה הראשונה במעלה, וללא ספק החמורה ביותר, היא שהתקן הזה חופף לתקן קיים. יש כיום תקן לשמירת מסמכים לצורך עריכה. הוא נקראOpen Document Format. הוא נשלט בידי גוף עם ייצוג רחב, כך שמי שמעוניין להשפיע על עתידו יכול להצטרף. במילים אחרות – תקן פתוח. הכנסת תקן חופף, בעיקר ע”י גוף חזק שהצהיר שהוא לא מתכוון לתמוך בתקן הקיים, בעצם מערערת את כל מה ש-ISO אמור להשיג.

מיקרוסופט, מצידה, מנסה לטעון שהדגש של OOXML הוא תמיכה בפורמטים ישנים. ניסיתי (בתגובה פה, וגם שלחתי אימייל אליו) להבין איך הטענה הזו מסתדרת עם מה שמיקרוסופט עושה בפועל, אבל לא הצלחתי לקבל תגובה.

על פי מיטב הבנתי, הבעיה הראשונה אמורה היתה להספיק כדי לדחות על הסף את התקן. למרות זאת, יש עוד בעיה, וגם היא חמורה. למעשה, מדובר על שתי בעיות. הראשונה היא ש-OOXML נכתב (אם נאמין לבלוג של Doug, בדיוק בהערה מעל ההערה שלי) כמשהו שמהווה צילום זכרון של מה שמיקרוסופט ממשו, ולא תקן שעומד בפני עצמו ואמור לעמוד לאורך זמן. מה שיותר גרוע, מיקרוסופט כבר הצהירה שהיא לא מתכוונת לוותר על שליטה בלעדית בכל הגרסאות העתידיות של התקן. במילים אחרות, מדובר פה על תקן שפשוט לא נועד לצריכה של הציבור הרחב. נראה, על פניו, שהגדרת 29500 כ”תקן בינלאומי” זו הצהרה ריקה מתוכן.

מה שמביא אותנו להשלכות האמיתיות. התקן אושר. יש כרגע חודשיים שבהם אפשר לערער על האישור, אבל ראיה מפוכחת אמורה להבהיר לנו שכל הסיכויים הם שהתקן הזה לא יידחה. הכינוי “ISO29500” יאפשר למיקרוסופט לטעון שהתוכנה שלהם תומכת בתקן בינלאומי, וכך לנסות להכנס לחוזים ממשלתיים ולמקומות אחרים, אבל בהחלט מדובר במקומות שממילא רצו את מיקרוסופט. אני לא חושב ששם עיקר הנזק.

הנזק היותר משמעותי הוא מה האדמה החרוכה שאישור התקן השאיר אחריו. התהליך של ISO היה מבוסס על אמון ועל קונצנזוס. זה עובד מצויין כאשר יש קבוצה של אנשים טכניים שעובדים ביחד למען תקנים טובים. ברגע שיש קבוצה שכל מטרתה היא לאשר מסמך ספציפי בתור תקן, טוב או לא טוב, כל הנהלים של ISO מתחילים להתמוטט. מה שיותר גרוע, חלק מהפעולות שמיקרוסופט עשתה כדי לגרום ל-29500 לעבור גרמו לסחף של מדינות שהפכו את הסטטוס שלהם למדינות מצביעות, מבלי שיש להם עניין בעבודה הכללית ש-ISO עושים, אלא רק בתקן הספציפי הזה. מכיוון שהנהלים של ISO הם מבוססי קונצנזוס, יש ל-ISO ספי קוורום להצבעות, גם אם המצביעים אומרים “נמנע”. הפלא ופלא, מתוך המצטרפים החדשים מעטים הם אלו שטורחים להחזיר את ההצבעה של המדינה שלהם, וכל התהליכים של ISO שלא קשורים ל-29500 פשוט משותקים. אם נוסיף לזה את הדיווחים על עיוותי נהלים שקרו בוועדות השונות, יש פה סכנה מאוד מהותית של משבר אמון בכל מה שקשור לעבודה של ISO. במילים אחרות, בהחלט ייתכן שתוך שנה מהיום 29500 יהיה תקן של ISO, אבל השם ISO יפסיק להיות שם שאנשים מתייחסים אליו ברצינות (ראו דברים קודמים שכתבתי בנושא החשיבות של תחזוקה של סמל).

לסיכום – אל תתמקדו בבעיות הטכניות של OOXML. כולן פתירות. מה שכנראה לא פתיר, אבל, אלו הן הבעיות המהותיות שהעברת 29500 כתקן, ובפרט הדרך שבה הוא הועבר כתקן, מעלות.

שחר

מאת

שחר שמש

מייסד–שותף וחבר ועד בתנועה לזכויות דיגיטליות מייסד שותף בעמותת „המקור”. פעיל קוד פתוח. מפתח שפת התכנות Practical

12 תגובות בנושא “ISO אישרו את OOXML – מה זה אומר על העתיד”

  1. אני מניח שידוע לך על פטנטים של מיקרוסופט שמשולבים בתקן שאם לא כן רוב הטיעונים שלך (הבדלה מ”התקן הפתוח”, חוסר יכולת להשפיע, שליטה של גוף וכו’) חסרים בסיס הכרחי.
    פרט לאמור OOXML הוא בעל חשיבות אדירה (כמו זו של PDF אם מחפשים מקבילה קנינית) בעצם התיעוד הפתוח של תסדיר המסמכים.

  2. פרט לאמור OOXML הוא בעל חשיבות אדירה (כמו זו של PDF אם מחפשים מקבילה קנינית) בעצם התיעוד הפתוח של תסדיר המסמכים.

    אבל אם זו הטענה שלך, אז הבעיות הטכניות מתחילות דווקא כן להיות רלוונטיות. בפרט, העובדה שאין גרסה של Office שמממשת את התקן במדוייק היא פתאום מאוד רלוונטית. כמובן שאפשר לטעון בדיוק את אותה הטענה כלפי ODF, אבל ברגע שאתה מגדיר את התקן כמטרה לשאוף אליה, זה פחות רלוונטי. אם אתה טוען שחשיבות התקן היא בהתנהגות הקיימת שהוא מתעד, אזי אם הוא לא מתעד התנהגות קיימת, זו בעיה אמיתית.

    לגבי PDF, אני לא יכול להגיד במפורש (לא מכיר מספיק), אבל על פי מיטב הבנתי, PDF הוא לא סתם תיעוד ריק של התנהגות נתונה, אלא פרוטוקול לא תלוי מימוש של תיאור מסמך סטטי. זה בדיוק מה שהיית מצפה מתקן (ואחת הנקודות המרכזיות שבהן OOXML כושל בהיבט הטכני, שהוא, כאמור, הפחות חשוב לדעתי).

    שחר

  3. ככלל עם הטיעונים האלו מאוד קל לי להסכים.

    אני בטוח גם ללא בדיקה כי התקן מכיל בעיות טכניות שונות ומשונות לפחות כמו כל תקן אחר.

    אני חולק על הטענה כי תקנים הם מטרה לשאוף אליה. יש המון תקנים , חלקם סותרים זה את זה, חלקם סתם הזויים משהו ובכל מקרה יש מקום לכולם בתנאי שהם כתובים בצורה שמאפשרת להתיחס אליהם כתקן.
    מקרה פרטי הוא המצב בו החוק מחייב עמידה בתקן מסויים אבל אפילו ל-ISO אין עדיין את הפריבילגיה שכל תקן המוכר על ידם יהפך אוטומטית למחוייב חוקית.

    בשורה התחתונה מנקודת ראותי במקרה זה התקבל מסמך עב כרס המתאר אופן הצגת מסמך בהסתמך על שימוש בתגים שונים כתקן שמי שרוצה יכול לממש אותו.
    אם אפילו מיקרוסופט לא ממשת אותו אז על אחת כמה וכמה תגובות האנטי שהסתייגת מהן היו מיותרות.

  4. מותר להגיב על הפוסט הקודם?
    בעצמם, במדינה שלהם, ובמקרה הכי גרוע, בשום דבר.

  5. א. מותר להגיב על הפוסט הקודם, אבל עדיף לעשות את זה בפוסט הקודם… 🙂
    ב. היה גם תוכן לפוסט, שדיבר על אנשים שחולים במחלות ומסתירים את זה כאילו שזו אשמתם. משום מה, אלוהי המחשבים אכל את כל גוף הפוסט!! ואני מתפלא שאנשים לא מגיבים….

    שחר

  6. האם מטרת התקן היא לתאר פורמט מסמכים של תוכנה מסויימת? אם כך למה מתארים כאן פורמט מסמכים חדש שלא היה בשימוש כלל במקום לתאר את פורמט המסמכים היותר מקובל של המסמכים שכבר נמצאים בשטח?

  7. הוא לא מכיל “אותה כמות של בעיות כמו כל תקן אחר”. הוא אושר במסלול מקוצר שנועד לתקנים שעברו הרבה יותר ביקורת. מסגרת הזמן שהוקדשה לאישורו לא הספיקה לדיון רציני ברבות מהבעיות.

    אם רוצים רק לתעד התנהגות של תוכנה קניינית, לא צריך את ISO.‏
    http://samba.org/samba/ms_license.html

    מצד שני, לא צריך להתייחס ברצינות רבה מדי לתקן שמתאר התנהגות של תוכנה מסויימת:‏
    http://www.ecma-international.org/publications/standards/Ecma-234.htm

  8. אני לא מכיר תקן שמטרתו לתאר את הקיים.
    גם אם על פי רוב המימוש מקדים את התיעוד שמוגש כתקן אין זה מלמד על המטרה לשמה מפורסם תקן.
    כמו ששחר ציין התקן הוא בסופו של דבר פירוט טכני (עם יתרונות וחסרונות) ועכשיו משפורסם יכולה מיקרוסופט (או כל גוף אחר אם אין בעיה של פטנטים) לממש אותו ולנצל את יתרונותיו הטכנולוגיים, לותר על חלקים ממנו ואם תרצה אז גם לזרוק אותו לעזאזל ולממש תקן שונה.

    למה לא לתאר את תסדיר המסמכים הנפוץ יותר?!
    הם מעונינים להוציא כלי המרה סגור, יקר וחסר תיעוד להעברת המסמכים הנפוצים לצורה תקנית

  9. יש מצב שאתה מסיים את העבודה על תקן הבידי בשבועיים הקרובים? כי אוטוטו אני אמור להתחיל להלחם איתו.

  10. אני מאוד מקווה שיש מצב שתוך שבועיים אני מתחיל לעבוד עליו 🙁

    בכל מקרה, זו תהיה עבודה ארוכה בגלל שחלק מאוד מהותי בה הוא הוצאת מימוש לבדיקה של הקהל הרחב. המימוש יהיה תחת רשיון שיאפשר לך לקחת את העבודה שלי, אז בתקווה עדיין יהיה מה להרוויח. אני מבטיח להודיע על זה פה.

    שחר

סגור לתגובות.