مثبت أداة الويبو للتسلسل – دليل التشغيل

1. سير العمل

يمكن استخدام الأداة في الحالات الأربع الآتية:

1. التحقق من صحة ملف بنسق WIPO ST.26.
2. وطلب حالة عملية تحقق جارية.
3. وتحديث ملفات الإعدادات (يقوم بذلك مسؤول مكتب الملكية الفكرية فقط).
4. واستدعاء نقطة النهاية الخاصة بمعاودة الاتصال للحصول على نتيجة عملية التحقُّق فور اكتمالها.

ملاحظة: إن نقطة النهاية الخاصة بمعاودة الاتصال ليست ضمن نطاق المثبت.  والمكاتب هي المنوطة بإنشاء هذه الخدمة وإعدادها لتحديد نقطة النهاية.

للتحقق من صحة من كشف تسلسلي بنسق WIPO ST.26، تستخدم الأداةُ ملفات XML المحلية الموجودة في هيكلية المجلد ، وتجري عملية تحقق، وتنشئ تقرير تحقق يحتوي على نتائج عملية التحقق. وبشكل اختياري، تعيد تقرير التحقق هذا عن طريق استدعاء نقطة النهاية الخاصة بمعاودة الاتصال.

وفيما يلي مسار العمل الرئيسي للمثبت:

• يحفظ نظام تكنولوجيا المعلومات الخاص بمكتب الملكية الفكرية المعني ملف XML في مجلد "Inbox" الافتراضي أو المجلد المُحدَّد ضمن الطلب.
• ويبدأ نظام مكتب الملكية الفكرية في إرسال البيانات حسب بروتوكول HTTP طالباً التحقق من الملف. وبحسب الإعدادات، يمكن لنظام مكتب الملكية الفكرية أن يطلب التحقق من الملف تحققاً "كاملاً" أو "شكلياً".  وستتأكد عملية التحقق "الشكلي" من أن ملف ST.26 هو ملف XML، وستتأكد من الملف أيضاً في ضوء مُعرِّف نوع الوثيقة (DTD) الخاص بالمعيار ST.26.  وأما في عملية التحقق "الكامل"، فسيجري التحقق من ملف ST.26 بناءً على قواعد التحقق من الأعمال، المستمدة من محتوى المعيار ST.26، بالإضافة إلى إجراء عملية التحقق "الشكلي".  

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

• وفور اكتمال التحقق، سيُقدَّم رد يُوضِّح هل الملف قد اجتاز التحقق "الشكلي" أم لا، وما إذا قد بدأت عملية التحقق من قواعد العمل بشكل صحيح في الملف الذي اختار فيه نظام تكنولوجيا المعلومات الخاص بمكتب الملكية الفكرية التحقق "الكامل".
• وإذا كان المثبت يجري عملية تحقُّق "كامل"، فإنه يسترد ملف XML من مجلد "Inbox" ويبدأ عملية التحقق من قواعد العمل، ثم يقوم بما يلي:
• وينشئ المثبتُ ملف تقرير XML ("تقرير التحقُّق") في مجلد "Output" المُحدَّد، وينقل ملف XML المتوافق مع معيار الويبو ST.26 الذي تم التحقق منه إلى مجلد "Outbox".
• وبعد اكتمال عملية التحقق من قواعد العمل، تُستدعى من المُثبت نقطة النهاية الخاصة بمعاودة الاتصال، في حالة ضبط إعداداتها، ويُزوَّد الطلب بمعلومات إضافية تتعلق بعملية التحقق. ويرد في القسم 2.2 أدناه هيكل الطلب وبعض البيانات النموذجية.
• وينبغي لنقطة النهاية الخاصة بمعاودة الاتصال أن ترد إما برمز فارغ وإما برمز نجاح عند الاستجابة (بدون أخطاء). [ملاحظة: لا تُنفَّذ هذه الخطوة إلا إذا كانت خدمة الويب الخارجية متاحة، وكان الاستدعاء قد ضُبطت إعداداته في المثبت.]  ولا بد أيضاً من وجود اتصال بين المثبت ونقطة النهاية الخاصة بمعاودة الاتصال.  وكما ذُكر أعلاه، لا تشكل خدمة الويب الخارجية جزءاً من المثبت، بل ينبغي أن تقوم المكاتب بإعدادها وتهيئتها وفقاً للعقد المُعرَّف أدناه.
• ويمكن لنظام مكتب الملكية الفكرية أن يسترد تقرير التحقُّق من مجلد "Report".

2. الاستخدام

الخطوة 1: تحديد التنسيق

كما أوضحنا آنفاً، يأتي ملف المثبت بأحد النسقين التاليين: ملف JAR الذي يمكن تنفيذه كخدمة ويب، أو ملف WAR الذي يمكن استخدامه على Tomcat server. وبناءً على نوع البنية التحتية التي يريد المكتب استخدام المثبت فيها، سيُفضِّل مكتب الملكية الفكرية اختيار أحد النسقين على الآخر.

والنسقان اللذان يُقدَّم بهما المثبت هما:

• Binary SpringBoot JAR: هذا الملف الثنائي هو ملف JAR قابل للتنفيذ. ويتطلب هذا الملف تثبيت Java 17.
• War Package Binary: ينبغي استخدام هذا الملف في حاوية Servlet. ولا بد من وجود خادم تطبيقات متوافق مع Spring Boot 3.1.0 وServlet Spec 4.0.1، مثل Tomcat 10.

وتتناول الأقسام التالية تفاصيل استخدام المثبت بوصفه تطبيق Spring Boot أو بوصفه ملف WAR داخل خادم تطبيقات Java.

• الخدمة باستخدام ملف JAR
• الخدمة باستخدام ملف WAR

يحتوي Spring Boot JAR على خادم مضمَّن يسمح باستخدام الواجهة البرمجية للمثبت دون الحاجة إلى خادم منفصل. ويؤدي ذلك إلى تبسيط كبير للإعداد والاستخدام على مستوى البنية التحتية.

لتشغيل الخادم المضمَّن، ينبغي تنفيذ الأمر التالي عندما يكون Java 17 مثبتاً بالفعل على الخادم:

java -jar wipo-sequence-validator.jar

ونظراً إلى أن Java لا يضمن استخدام UTF-8، يجب ضبط خاصية "file.encoding" في النظام على "UTF-8". وسيعمل الخادم في المنفذ 8080 بشكل افتراضي، ولتغيير المنفذ، ينبغي إضافة خيار سطر الأوامر "--server.port" كما هو أدناه. ويمكن القيام بذلك عن طريق إدراج ما يلي:

java -D"file.encoding=UTF-8" -jar wipo-sequence-validator.jar –-server.port=<port-number>

ويمكن الوصول إلى الواجهة البرمجية للمثبت من خلال Swagger UI بعد استخدام ملف JAR، حيث يجب على مكتب الملكية الفكرية إجراء التغييرات التالية: يجب الاستعاضة عن [host-name] باسم مضيف الخادم:

 http://[host-name]:8080/wipo-sequence-validator/swagger-ui/index.html

يمكن الوصول إلى الواجهة البرمجية للمثبت في نقاط النهاية التالية:

• طريقة GET: 

  http://[host-name]:8080/wipo-sequence-validator/api/v2.0/status/validationId

• طريقة POST: 

  http://[host-name]:8080/wipo-sequence-validator/api/v2.0/validate

سيستخدم المثبت إعدادات الذاكرة الافتراضية لجهاز جافا الظاهري (JVM) بشكل افتراضي. والحد الأقصى الافتراضي لحجم كم المعلومات هو ربع الذاكرة الفعلية المتاحة. ولتعديل الحد الأقصى لحجم كم المعلومات، يجب استخدام الخيار "-Xmx" عند التنفيذ باستخدام سطر الأوامر:

java -D"file.encoding=UTF-8" -Xmx[size]-jar wipo-sequence-validator.jar

يمكن أيضاً تثبيت المثبت كخدمة يديرها نظام التشغيل، لدعم تنفيذه عند بدء نظام التشغيل على سبيل المثال. ويمكن تهيئة ملف Spring Boot JAR بهذه الطريقة في جميع المنصات التي تعمل عليها أداة الويبو للتسلسل: نظام Windows، ونظام Linux، ونظام Mac OS.

ويقدم الدليل التالي تفاصيل عن كيفية إنشاء خدمة نظام تقوم بتنفيذ ملف JAR لكل نظام من أنظمة التشغيل. كما يقدم معلومات عن كيفية ضبط إعدادات الخيارات المختلفة للخدمة وتنفيذ التطبيق.

وفيما يخص النوع الثاني من الملفات الثنائية المتوفرة، يمكن استخدام حزمة WAR في خادم تطبيقات Java موجود مثل Apache Tomcat 10. ملاحظة: لا بد من وجود حاوية متوافقة مع Servlet 4.0.1.

الإرشادات التالية خاصة بخادم تطبيقات Tomcat. وهنا،

$TOMCAT_ROOT

تشير إلى المجلد الجذر لخادم Tomcat، وينبغي الاستعاضة عن هذه القيمة بالقيمة الخاصة بمسار الملف:

• إيقاف السيرفر:

  $TOMCAT_ROOT\bin\catalina.bat stop

• نسخ ملف WAR إلى

  $TOMCAT_ROOT\webapps\wipo-sequence-validator.war

• بدء الخادم:

  $TOMCAT_ROOT\bin\catalina.bat start

ملاحظة: نظراً إلى أن Java لا يضمن استخدام UTF-8، يجب ضبط خاصية "file.encoding" في النظام على "UTF-8". ويمكن القيام بذلك عن طريق إدراج ما يلي: -D"file.encoding=UTF-8"

يمكن الوصول إلى الواجهة البرمجية للمثبت من خلال Swagger UI، على النحو المُوضَّح أعلاه:

http://host-name:8080/wipo-sequence-validator/swagger-ui/index.html

ويمكن الوصول إلى الواجهة البرمجية للمثبت في نقاط النهاية التالية، حيث يجب الاستعاضة عن اسم المضيف [host-name] باسم مضيف الخادم:

• طريقة GET:

  http://[host-name]:8080/wipo-sequence-validator/api/v2.0/status/validationId

• طريقة POST:

  http://[host-name]:8080/wipo-sequence-validator/api/v2.0/validate 

سيعمل الخادم عبر المنفذ 8080 بشكل افتراضي. ولتغيير ذلك والانتقال إلى منفذ آخر، ينبغي تعديل ملف تهيئة Tomcat عن طريق اتباع الإرشادات المقدمة هنا:

https://tomcat.apache.org/tomcat-10.0-doc/config/index.html

سيستخدم المثبت إعدادات الذاكرة الافتراضية لجهاز جافا الظاهري (JVM) بشكل افتراضي. والحد الأقصى الافتراضي لحجم كم المعلومات هو ربع الذاكرة الفعلية المتاحة.

من أجل تعديل الحد الأقصى لحجم كم المعلومات، يجب استخدام الخيار "-Xmx" عند التنفيذ باستخدام سطر الأوامر، كما هو موضح أعلاه.

الخطوة 2: إنشاء نظام المجلدات

تتألف بنية نظام الملفات الذي يستخدمه المثبت من خمسة مجلدات رئيسية:

• مجلد "Inbox": هذا هو المجلد المحلي الذي يحتوي على الملفات المتوافقة مع معيار الويبو ST.26 المُقدَّمة من مكتب الملكية الفكرية للتحقق منها.
• مجلد "Process": هذا هو المجلد المحلي الذي تمر من خلاله مؤقتاً الملفات الموجودة في مجلد "Inbox" في أثناء المعالجة. ويحتوي هذا المجلد على مجلدين فرعيين. ويحتوي هذا المجلد على مجلدين فرعيين:
  • مجلد "Full validation": تُحفظ فيه الملفات انتظاراً لخضوعها للتحقق الكامل.
  • مجلد "Formality validation": تُحفظ فيه الملفات انتظاراً لخضوعها للتحقق الشكلي
• مجلد "Outbox": فور اكتمال عملية التحقق، يقوم التطبيق بحفظ مصدر الملف المتوافق مع معيار الويبو ST.26 في هذا المجلد المحلي.
• مجلد "Report": هذا هو المجلد المحلي الذي تُحفظ فيه نتائج التحقق في ملف تقرير التحقق.
• مجلد "Params": هذا هو المجلد المحلي الذي يوجد فيه ملف JSON (.json) مع جميع معايير التحقق المُستقاة من طلب التحقُّق من أجل توفير معايير لعملية التحقق العميق غير المتزامنة.

وفيما يلي مثال على بنية نظام الملفات:

الخطوة 3: الاختبار

يمكن إجراء اختبار خدمة المثبت باستخدام تطبيق Postman، وذلك باتباع الخطوات التالية:

• افتح تطبيق Postman وأنشئ طلباً جديداً
• أضف معلومات متن الطلب:
• بعد الضغط على "Send" يجب أن يكون الرد كالتالي:

3. الطلب

طلب نقطة النهاية الخاصة بمعاودة الاتصال

سيقوم مثبت أداة الويبو للتسلسل، بعد الانتهاء من طلب التحقق، بإنشاء ملف JSON يتضمن المعلمات اللازمة لطلب نقطة النهاية الخاصة بمعاودة الاتصال. وينبغي أن يشتمل الطلب على المعايير التالية التي توضح بالتفصيل مواقع الملفات وعملية التحقُّق:

{ "currentApplicationNumber": "string", "currentSEQLVersionNumber": "string", "patentApplicationNumber": "string", "seqlInputLocation": "string", "verificationReportOutputPath": "C:/temp/st26/reports/", "nameFile": "valid2Warning.xml", "type": "FULL" }

وينبغي أن يشير الحقل "seqlInputLocation" في طلب التحقق إلى مسار الكشف التسلسلي ذي النسق XML المطلوب التحقق منه. وإذا ترك المكتب هذا الحقل فارغاً، فستحاول الأداة أن تتحقق من ملف XML باستخدام اسم الملف "nameFile" الموجود في مجلد "Inbox" الافتراضي. ويُحدِّد المعيار "nameFile" ملف الكشف التسلسلي المطلوب التحقق منه.

أما المعيار "verificationReportOutputPath" الموجود داخل الطلب فسيُقدِّم موقع ملف تقرير التحقق (.xml) الذي أنشأته الأداة. وإذا ترك المستخدم هذا الحقل فارغاً أو أدخل مسار ملف غير صحيح، فسيُحفظ تقرير التحقق في مجلد "Reports" الافتراضي.

في حالة ضبط الخاصية "api.URL"، سيحاول المثبت إرسال نتائج التحقق إلى نقطة نهاية في العنوان المُحدَّد.

وللتواصل مع المثبت، يجب أن تتوافق نقطة النهاية الخاصة بمعاودة الاتصال مع عقد خدمة الويب التالي (YAML).

وعلاوة على ذلك، يجب أن يكون الطلب كائن JSON بهذه البنية:

{ "currentApplicationNumber": "string", "currentSEQLVersionNumber": "string", "elapsedTime": 0, "endTime": "string", "errorSummary": [ { "dataElement": "string", "detectedSequence": "string", "index": 0, "key": "string", "locmessage": "string", "params": { "additionalProp1": "string", "additionalProp2": "string", "additionalProp3": "string" }, "paramsForXML": [ { "key": "string", "value": "string" } ], "reportValue": "string", "sequenceIDNumber": "string", "type": "string" } ], "httpStatus": "string", "parentApplicationNumber": "string", "parentSEQLVersionNumber": "string", "processID": "string", "seqIDQuantity": 0, "seqInputQuantity": 0, "seqlType": "string", "startTime": "string", "totalErrorQuantity": 0, "totalWarningQuantity": 0, "verificationReportOutputPath": "string"

هذا مثال على مثيل JSON سيُرسَل إلى نقطة النهاية الخارجية التي أجرت استدعاء للمثبت:

{ "processID": "1608194222169dvVE", "seqlType": "ST.26", "httpStatus": "SUCCESS", "currentApplicationNumber": "string", "currentSEQLVersionNumber": "string", "parentApplicationNumber": "string", "parentSEQLVersionNumber": "string", "verificationReportOutputPath": "C:/temp/report.xml", "startTime": "2020-12-17 09:36:54.000000", "endTime": "2020-12-17 09:37:26.000607", "elapsedTime": 32607, "totalWarningQuantity": 1, "totalErrorQuantity": 2, "seqInputQuantity": 3, "seqIDQuantity": 3, "errorSummary": [ { "index": 0, "reportValue": "", "type": "WARNING", "params":com.wipo.st26.ipotool.models.ServiceRequest@5887858, "key": "X_EARLIEST_PRIO_APPLICATION_ID_MISSING", "locmessage": "Earliest priority application information is absent. It must be provided when a priority claim is made to an earlier application.", "detectedSequence": "", "dataElement": "PROPERTY_NAMES.EARLIEST_PRIORITY_APPLICATION" }, { "index": 0, "reportValue": "-", "type": "ERROR", "params": {}, "key": "INVENTION_TITLE_MISSING", "locmessage": "The invention title is missing. At least one invention title must be entered.", "detectedSequence": "", "dataElement": "PROPERTY_NAMES.INVENTION_TITLE_BAG" }, { "index": 1, "reportValue": "-", "type": "ERROR", "params": {}, "key": "INVENTION_TITLE_MISSING", "locmessage": "The invention title is missing. At least one invention title must be entered.", "detectedSequence": "", "dataElement": "PROPERTY_NAMES.INVENTION_TITLE_BAG" } ] }

4. التقرير

تقرير التحقق

وتُنشئ أداة الويبو للتسلسل تقرير التحقق بنسق XML، وبشكل اختياري HTML، باستخدام نفس جدول الأنماط المستخدم في أداة الويبو للتسلسل. والسمات المشار إليها على مستوى الجذر هي كالآتي:

• "applicationNumberText": الطلب المرتبط بالكشف التسلسلي هذا؛
• "productionDate": تاريخ إجراء التحقق؛
• "filingDate": تاريخ إيداع الطلب؛
• "softwareBuildVersion": إصدار المثبّت المستخدم للتحقق؛
• "softwareVersion": إصدار أداة الويبو للتسلسل المستخدم لإنشاء الكشف التسلسلي؛
• "sourceFileName": اسم الكشف التسلسلي لنموذج XML.

النموذج، أو الملف بنسق XSD، الذي يُستخدم لإنتاج تقرير التحقق هو كما يلي:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <VerificationReport productionDate="YYYY-MM-DD" sourceFileName="[ST.26 filename]"> <VerificationMessageBag> <VerificationMessage> <Severity>[ERROR | WARN | XML_WARN | XML_ERROR]</Severity> <DataElement>[ST.26 element]</DataElement> <DetectedSequence>[Sequence ID]</DetectedSequence> <DetectedValue>[value]</DetectedValue> <MessageKey>[Message key]</MessageKey> <ParameterBag> <Parameter key="param key">Param value</Parameter> <ParameterBag> <LocalizedMessage> [Localized message] </LocalizedMessage> </VerificationMessage> ... </VerificationMessageBag> </VerificationReport>

وبالنسبة إلى درجة الشدة، يُرجى ملاحظة التصنيف التالي:

• "ERROR"– خطأ ظهر خلال التحقق "الكامل"
• "WARNING" - تحذير ظهر خلال التحقق "الكامل"
• "XML_ERROR" – خطأ ظهر خلال التحقق "الشكلي"
• "XML_WARN" - تحذير ظهر خلال التحقق "الشكلي"

وبعد عملية التحقق، يُوضع تقرير التحقق الذي تم إنشاؤه بأحد التنسيقين أو كليهما في "verificationReportOutputPath"، والذي يكون افتراضياً في الموقع التالي:

./temp/st26/reports/[verificationID]/

ويرد مثال لتقرير التحقق بنسق XML في الموارد أدناه.

5. ضبط الإعدادات

الإعدادات الافتراضية

تُضبط إعدادات المثبت باستخدام ملف خصائص. ويمكن الاطلاع على القيم الافتراضية في *ملف application.yml المنشور*.

ولتعديل قيم المعايير الموجودة، ينبغي استخدام ملف "application.yml" بديل. وهناك العديد من الخيارات كما هو مُفصّل في وثائق Springboot.

ويمكن تحديد مسار ملف الإعدادات واسمه عن طريق إنشاء المعيار في سطر الأوامر عند بدء تشغيل الأداة:

• في حالة استخدام ملف JAR:

  java -jar -Dspring.config.location= <PATH_TO_FILE> wipo-sequence-validator.jar

• في حالة استخدام ملف WAR على Tomcat، يجب إضافة البند التالي إلى CATALINA_OPTS:
  • نظام ويندوز:

    set SPRING_CONFIG_ADDITIONAL-LOCATION=-Dspring.config.location=<PATH_TO_FILE>

  • نظام لينوكس:

    export SPRING_CONFIG_ADDITIONAL-LOCATION="-Dspring.config.location=<PATH_TO_FILE>

عند استخدام ملف WAR، يمكن أيضاً نسخ ملف "application.yml" الجديد إلى مجلد "WEB-INF/classes" الخاص بتطبيق الويب.

وفي "ملف application.yml"، يمكنك تمكين أو تعطيل إنشاء تقرير بنسق HTML. وتستخدم القيمة "true" لتمكين إنشاء التقرير وقيمة "false" لتعطيله. ويُرسَل محتوى هذا التقرير إلى نقطة النهاية الخاصة بمعاودة الاتصال داخل حقل "errorSummary" في "ServiceRequest"

قاعدة التحقق VXQV_49

من الممكن وضع القيمة "optionalEnglishQualifierValue" على أنها "true" إذا كان المستخدم يريد تفعيل القاعدة VXQV_49، ومن الممكن أيضاً ضبط درجة الشدة في القاعدة عن طريق تحديث القيمة "optionalRuleType" لتكون 'ERROR' أو 'WARNING'.

نقطة السلامة

يوجد في المثبت خاصية سلامة نقطة النهاية "health/"، التي توفّر معلومات أساسية حول سلامة التطبيق. ولاستكشاف سلامة نقطة النهاية، لا بد من فتح الرابط التالي:

وينبغي أن تعرض نقطة النهاية ما يلي:

• ستكون الحالة "UP" مادام التطبيق سليماً.
• ستظهر الحالة "DOWN" إذا أصبح التطبيق غير سليم بسبب أي مسألة من المسائل، مثل الاتصال بقاعدة البيانات أو عدم وجود مساحة في القرص أو غير ذلك.

ولا تظهر خاصية سلامة نقطة النهاية "health" سوى الحالتين "UP" أو "DOWN". وتتيح الخاصية التالية في ملف "application.yml" التفاصيل الكاملة، بما في ذلك حالة السلامة الخاصة بكل مؤشر من المؤشرات التي تم فحصها كجزء من عملية فحص السلامة.

وباتت خاصية سلامة نقطة النهاية الآن تتضمن تفاصيل عن “DiskSpaceHealthIndicator” الذي يُنفذ كجزء من عملية فحص السلامة.

وستعرض سلامة نقطة النهاية البيانات على النحو التالي:

رسائل مُترجَمة

يمكن للمثبت أن يقدم رسالة مُترجَمة، في تقرير التحقق مثلاً، بكل لغة من اللغات الرسمية العشر لمعاهدة التعاون بشأن البراءات (العربية والصينية والإنكليزية والفرنسية والألمانية والبرتغالية واليابانية والكورية والروسية والإسبانية).

وتُقدَّم هذه الرسائل باللغة الإنكليزية بشكل افتراضي. ولضبط المثبت من أجل تقديم هذه الرسائل بلغة أخرى، يجب ضبط المعيار "validator_locale" على رمز اللغة المطلوبة.

أسماء الكائنات المخصصة

لكي تقدم المكاتب أسماء الكائنات المخصصة الخاصة بها، التي لا توجد في القائمة الأصلية المُحدَّدة مسبقاً لأسماء الكائنات، يمكن تقديم قائمة بالكائنات المخصصة عن طريق إنشاء ملف جديد باسم "custom_organism.json" في المجلد "alternativeResourceBasePath". وينبغي أن تكون بنية هذا الملف على النحو التالي:

إصدار DTD بديل

افتراضياً، تشير أداة التحقق إلى الإصدار الأحدث من مُعرِّف نوع الوثيقة الخاص بالمعيار ST.26 (ST.26 DTD). ويستند الإصدار الحالي من مثبت أداة الويبو للتسلسل إلى الإصدار 1.3 من WIPO ST.26 DTD. وتُدرَج هذه النسخة من أحدث إصدارات ST.26 DTD في مكتبة المثبت الموجودة في المجلد "/src/main/resources" في الشفرة المصدرية (هذا هو مسار الملف المُحدَّد المشار إليه في ملف JAR أو WAR). ويُشار إليها في الملف "catalog.xml" في المجلد نفسه.

وفي أثناء التحقُّق، سيُستخدم إصدار DTD المُحدَّد في إقرار DOCTYPE لملف XML. أولاً، سيُستخدم "publicId" لتحديد موقع ملف DTD الذي يجب استخدامه. وفي حالة عدم وجود "publicId" في الكتالوغ، سيحاول النظام تحديد موقع ملف DTD في المجلد الجذر الذي تُنفَّذ فيه عملية Java.

من أجل التحقق من ملفات معيار الويبو ST.26 التي تشير إلى إصدار أقدم من ST.26 DTD، يجب إتاحة ملف ST.26 DTD هذا للمثبت من أجل السماح بإجراء التحقق المناسب. وهناك طريقتان بديلتان لتحقيق ذلك:

1. فكّ ضغط ملف JAR، وأدرج إشارةً إلى ملف ST.26 DTD الإضافي أو البديل في المجلد "src/main/resources". عدِّل ملف "catalog.xml"، وأضف بنداً جديداً لملف ST.26 DTD الإضافي، أو قم بتحرير البند الحالي. على سبيل المثال:

1. بدلاً من تعديل ملف JAR، ينبغي اتباع الخطوات التالية:
   "1" انسخ "catalog.xml" وجميع ملفات DTD إلى مجلد محلي؛
   "2" وعدِّل "catalog.xml" لإدراج إشارة إلى ملف ST.26 DTD الإضافي؛ "3" واضبط خاصية نظام Java هذه عند التشغيل: "xml.catalog.files=<path_to_catalog.xml>"

في Tomcat على نظام ويندوز، يمكن القيام بذلك عن طريق إضافة متغير البيئة التالي:

6. الموارد

قد تكون الموارد التالية مفيدة لمكاتب الملكية الفكرية:

• مثال على تقرير التحقق
• المواصفات الكاملة للواجهة البرمجية (YAML)
• أسماء الخصائص، JSON