XML دروس بسيطة ثلاثة

مستقبل XML الآن أنت تعرف XML. صحيح أن البنية معقدة بعض الشيء، ولدى DTD خيارات متنوعة لتحديد ما يمكن أن تحتوي عليه الوثيقة. ولكن هذا ليس كل شيء.

خذ بعين الاعتبار الصناعة التي يعد تبادل البيانات فيها أمرًا مهمًا، مثل الخدمات المصرفية. تستخدم البنوك أنظمة الملكية لتتبع المعاملات داخليًا، ولكن إذا كانت تستخدم تنسيق XML شائعًا على الويب، فيجب عليها وصف معلومات المعاملة لمؤسسة أو تطبيق آخر (مثل Quicken أو MS Money). وبطبيعة الحال، يمكنهم أيضًا تمثيل البيانات على صفحات الويب. لمعلوماتك: هذه العلامة غير موجودة. يطلق عليه OFEX، البورصة المالية المفتوحة.

في ظل ظروف معينة، إذا واجه IE 4 على جهاز الكمبيوتر علامة <SOFTPKG>، فسيتم بدء وظيفة لمنح المستخدم الفرصة لتحديث البرامج المثبتة. إذا كنت تستخدم نظام التشغيل Windows 98، فربما تكون قد شاهدت هذا الموقف، ولكنك لم تعلم أنه تطبيق XML.

لدينا هنا ثلاثة تطبيقات XML تبدو مختلفة عن آلات الجمع والآلات الكاتبة وأقلام الرصاص التي شاهدها آندي جروف في السبعينيات. ولكن على غرار التطبيقات التي ظهرت في نهاية المطاف على أجهزة الكمبيوتر، يمكن وصف فوائد لغة XML عمومًا على النحو التالي: "عندما تستخدم علامات يمكن قراءتها بواسطة الإنسان والآلية لوصف بياناتك، تحدث

تلك الأشياء الجيدة

؟ ليس لدي أي فكرة. لكنني أيضًا لا أعرف كيف سيبدو الجيل التالي من البرامج على جهاز الكمبيوتر الخاص بي. وطالما تم وضع علامة على البيانات بهذه الطريقة، يمكن إنشاء تطبيقات مختلفة.

هل بدأت بالتفكير في المدى الذي يمكن أن تتوسع فيه؟

لدينا الكثير من التطبيقات العملية لـ XML لنتحدث عنها، وسأقوم بتغطيتها في المستقبل القريب. وبما أننا جميعاً مستخدمين للإنترنت، فإن المستقبل سيكون XSL (لغة الأنماط القابلة للتوسيع).
لغة النمط الموسعة).

بالمناسبة، هذه الوصفة لأمي بالفعل وهي رائعة. إذا كنت تستخدم ذلك، أضف نصف كوب آخر من جوز الهند المبشور.

أنا أكتب هذا لأنني أهتم حقًا بما تعتقده عني. ما يقلقني هو ما يلي: إذا قرأت مقدمتي عن XML وكنت مستعدًا لبدء كتابة مستندات XML الخاصة بك. لذلك تبدأ في البحث عن DTD محدد بالفعل لتمثيل معلوماتك. تجد واحدا كما هو موضح أدناه:

<!ATTLIST fn

%attr.lang;

value CDATA #FIXED "TEXT">

<!ENTITY % attr.img "

img.type CDATA #REQUIRED

img.data ENTITY #REQUIRED">

على الفور تعتقد أن جاي يجب أن يكون أحمق. لم يقل أي شيء عن ATTLIST وENTITY - مهما كانا.

لذلك دعونا نتحدث عن هذا، أولاً مع القليل من الصبر.

قد لا تبدو السطور أعلاه جيدة، لكنها في الواقع لا شيء. يتم استخدامها في DTDs لتحديد السمات والكيانات في مستندات XML. أي شخص يعرف HTML سيعرف هذا جيدًا. السمات هي إدخالات تحتوي على علامات HTML تصف العلامات بشكل أكثر دقة. في <img src="my.gif" height="20" width="20"> الذي يظهر بشكل متكرر، هناك سمتان: الارتفاع والعرض. كما سترى لاحقًا، فإن استخدام السمات في مستندات XML مشابه جدًا.

لا يوجد شيء جديد بشأن الكيانات أيضًا. إذا كنت قد استخدمت &، فأنت تعرف الأساسيات بالفعل. تمثل السلسلة المحاطة بـ & والفواصل المنقوطة حرفًا آخر أو مجموعة من الأحرف. (القائمة الكاملة لكيانات ISO متاحة هنا.)

بالطبع، السمات والكيانات في XML لها وظائف أخرى. يقدم هذا حتمًا بناء الجملة، على الرغم من أنه ليس كثيرًا. بمجرد معرفة ذلك، سيكون العمل مع مستندات XML أمرًا سهلاً.

وصفات مبسطة

إذا قرأت مقدمتي عن لغة XML، فسوف تتذكر أن المكونات الموجودة في الوصفة يتم تمثيلها بعلامات بسيطة، مثل <item>2 كوب دقيق</item>. بعد كتابة هذا المقال، كنت أتجول في الويب ووجدت مستند XML آخر حول الوصفات. عناصر الوصفة هي كما يلي:

<ingredient الكمية = "2" Units = "cups">الدقيق</ ingredient>

هذا الأسلوب له فائدة عملية: فهو يسهل التحكم في البيانات. مع الطريقة الأولى، يتم استخدام العلامة <item> للاحتفاظ بمجموعة من المعلومات المختلفة. إذا أردت استخراج قائمة المكونات دون مقادير كل مكون، فلن أفعل ذلك.

يمكنني تحقيق وظائف مماثلة باستخدام البنية التالية:

<item>دقيق

<quantity>2</quantity>

<units>أكواب</units>

يمكن معالجة ذلك، ولكن هناك مشكلتان: أولاً، يحتوي عنصر العنصر على محتوى مختلط: نص وترميز آخر. لقد اكتشفت بسرعة أنه يجب تجنب هذا الهيكل كلما أمكن ذلك. والثاني هو أن العلامات ليس لها أي معنى مستقل تقريبًا. من الصعب أن نتخيل موقفًا حيث توجد وحدات فقط ولكن لا توجد مكونات فعلية. يمكن وصف هذه العناصر ببساطة، أفضل أن أفكر فيها كخصائص.

أول شيء يجب ملاحظته هو أن أسماء السمات والكميات والوحدات تكون ذات معنى فقط عند معالجتها بواسطة تطبيق يمكنه ترجمتها.

يجب إخبار DTD بالسماح بذلك قبل تضمينه في مستند صالح. بالنسبة للعنصر المكون أعلاه، قمنا فقط بتضمين الكود التالي في DTD:

<!عنصر العنصر #PCDATA>

<!كمية مكون ATTLIST CDATA #REQUIRED>

<!وحدات مكون ATTLIST CDATA #REQUIRED>

يبدو السطر الأول مألوفًا - تعريفات العناصر القياسية التي ستراها في أي DTD. يحتوي كل سطر ATTLIST على المعلومات التالية بدوره:

<!ATTLIST كمية المكونات CDATA #REQUIRED>

هذا هو العنصر الذي تم إرفاق السمة به.

<!ATTLIST كمية المكونات CDATA #REQUIRED>

يتم تعريف اسم السمة هنا.

<!ATTLIST كمية المكونات CDATA #REQUIRED>

قم بتعيين نوع السمة هنا. CDATA لتقف على بيانات الشخصية. وهذا يعني أن المعالج يمكنه الحصول على النص داخل السمة.

<!ATTLIST كمية المكونات CDATA #REQUIRED>

يحدد الجزء الأخير القيمة الافتراضية للسمة. يمكنك استخدام قيمة عددية فعلية، مثل 3. بهذه الطريقة، ستكون قيمة السمة لطول المسافة البيضاء في XML هي 3. ستتجاوز القيمة المدخلة القيمة الافتراضية.

في المثال أعلاه، لم أقم بتعيين كمية محددة، ولكنني استخدمت الكلمة الأساسية XML #REQUIRED. يخبر المعالج أن السمة الثانوية يجب أن تحتوي على قيمة. إذا كان فارغًا، فلن تتم معالجة المستند.

تحتوي القيمة الافتراضية على كلمتين رئيسيتين إضافيتين. الأول هو #FIXED - إذا ظلت قيمة السمة بنفس القيمة في المستند بأكمله. لنفترض أنني قمت بتحديد سمة علامة صورة، وجميع الصور بنفس الحجم، مثل 100*50 بكسل، يمكنني تحديد السمة مثل هذا في DTD:

<!طول الصورة ATTLIST CDATA #FIXED "100 بكسل">

<!عرض الصورة ATTLIST CDATA #FIXED "50 بكسل">

الكلمة الرئيسية الأخرى هي #IMPLIED، مما يشير إلى أن الخاصية يمكن أن تحتوي على قيمة أو أن تكون فارغة.

دعونا نلقي نظرة على أنواع السمات.

إذا قررت كتابة DTD الخاص بك، فقد تحتاج إلى كتاب يشرح XML لجميع المجموعات في بيان ATTLIST. ولكن إذا قمت باستعارة DTD، فقد لا تعرف سوى CDATA وثلاث سمات أخرى.

الأول هو الهوية. يتطلب عدم تكرار قيمة السمة في المستند. يعرف أي شخص يستخدم قاعدة بيانات الحاجة إلى معرفات فريدة. تبدو عبارة DTD ATTLIST بالشكل التالي:

<!ATTLIST element_name attribute_name ID #REQUIRED>

من الصعب تخيل نوع سمة المعرف بدون القيمة الافتراضية #REQUIRED. في هذه الحالة، أي معرفات مكررة أو فارغة ستجبر المعالج على إرجاع خطأ. يجب أن يبدأ المعرف بحرف أو شرطة سفلية ولا يمكن أن يحتوي على أي مسافات.

يستخدم نوع NMTOKEN أيضًا قواعد التسمية المذكورة أعلاه. لكن الازدواجية مسموحة. يتم استخدامه كضمان لتمرير البيانات إلى التطبيق. لا يمكن أن تحتوي معظم لغات البرمجة، بما في ذلك Java وJavaScript، على مسافات في أسماء الوحدات النمطية. في معظم الحالات، من الأفضل التأكد من امتثال العقارات لقواعدها.

وأخيرًا، هناك أنواع التعداد التي لا تتطلب كلمات رئيسية محددة. بدلاً من ذلك، استخدم الرمز "|" لإحاطة القيمة بين قوسين، على سبيل المثال:

<!ATTLIST sibling (brother | sister) #REQUIRED>

يمكن استخدام هذا الأسلوب إذا كان هناك عدد محدود من قيم السمات المحتملة.

لا تعتقد أن دورة اليوم مملة، لذا استمر في القراءة!