כמעט תמיד נעשה שימוש לרעה ב-XML

שפת ה-XML הומצאה בשנת 1996. ברגע שהוא הופיע, האפשרויות של יישומו כבר החלו להיות מוטעות, ולמטרות אליהן ניסו להתאים אותה, זו לא הייתה הבחירה הטובה ביותר.

אין זה מוגזם לומר שהרוב המכריע של סכימות XML שראיתי היו שימושים לא הולמים או שגויים ב-XML. יתרה מכך, השימוש הזה ב-XML הוכיח אי הבנה בסיסית של מה מדובר ב-XML.

XML היא שפת סימון. זה לא פורמט נתונים. רוב סכימות ה-XML התעלמו במפורש מההבחנה הזו, תוך שהיא מבלבלת בין XML לפורמט נתונים, מה שבסופו של דבר מביא לטעות בבחירת ה-XML כי זהו פורמט הנתונים שבאמת נחוץ.

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

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

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

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

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

<root name="John" city="London" />

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

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

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

ביטוי מילון נכון ב-XML ייראה בערך כך:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

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

סכימת XML הגרועה ביותר? אגב, הפרס עבור סכימת ה-XML הגרועה ביותר שראיתי אי פעם, מקבל את פורמט קובץ תצורת ההקצאה האוטומטית עבור טלפונים טלפוניים IP של Polycom. קבצים כאלה דורשים הורדת קבצי בקשת XML דרך TFTP, אשר... באופן כללי, הנה קטע מקובץ אחד כזה:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

זו לא בדיחה גרועה של מישהו. וזו לא המצאה שלי:

• אלמנטים פשוט משמשים כתחילית לצרף תכונות, אשר בעצמן יש שמות היררכיים.
• אם ברצונך להקצות ערכים למספר מופעים של סוג מסוים של רשומה, עליך להשתמש בשמות מאפיינים לשם כך. שיש להם אינדקסים.
• בנוסף, תכונות שמתחילות ב softkey., חייב להיות ממוקם על אלמנטים <softkey/>, תכונות שמתחילות ב feature., חייב להיות ממוקם על אלמנטים <feature/> וכו', למרות שזה נראה מיותר לחלוטין ובמבט ראשון חסר משמעות.
• ולבסוף, אם קיווית שהרכיב הראשון של שם תכונה יהיה תמיד זהה לשם האלמנט - שום דבר כזה! למשל, תכונות up. חייב להיות מחובר אליו <userpreferences/>. סדר הצמדת שמות תכונות לאלמנטים הוא שרירותי, כמעט לחלוטין.

מסמכים או נתונים. מדי פעם, מישהו עושה משהו מוזר לחלוטין על ידי ניסיון להשוות בין XML ל-JSON — ובכך להראות שגם הוא לא מבין. XML היא שפת סימון מסמכים. JSON הוא פורמט נתונים מובנה, אז השוואה ביניהם זה כמו לנסות להשוות בין חם לרך.

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

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

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

במילים אחרות, ניתן להמיר מילון (חתיכת נתונים מובנים). n מסמכים אפשריים שונים (ב-XML, PDF, נייר וכו'), היכן n - מספר השילובים האפשריים של אלמנטים במילון, ועדיין לא לקחנו בחשבון משתנים אפשריים אחרים.

עם זאת, נובע גם שאם אתה רוצה להעביר נתונים בלבד, אז השימוש במסמך קריא במכונה עבור זה לא יהיה יעיל. הוא משתמש במודל, שבמקרה זה מיותר; הוא רק יפריע. בנוסף, על מנת לחלץ את נתוני המקור, תצטרך לכתוב תוכנית. אין כמעט טעם להשתמש ב-XML עבור משהו שלא יעוצב כמסמך בשלב מסוים (נניח, באמצעות CSS או XSLT, או שניהם), מכיוון שזו הסיבה העיקרית (אם לא היחידה) לעשות זאת. למודל המסמך.

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

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

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

עד כה, סכימות ה-XML היחידות שאני יודע עליהן שאני באמת יכול לקרוא להן שימוש חוקי בפורמט הן XHTML ו-DocBook.

מקור: www.habr.com