Jelaskan aturan yang gagal
A BIMI Validator SVG harus mengidentifikasi aset kandidat, kumpulan aturan yang berlaku, dan persyaratan pasti yang gagal. Pesan seperti logo yang tidak valid tidak cukup bagi perancang atau operator untuk memperbaiki aset dengan aman. Validator harus membedakan format XML yang salah, struktur SVG yang tidak didukung, batasan khusus profil, rekomendasi penerima, dan masalah visual. Kategori-kategori tersebut dapat tumpang tindih, namun tidak dapat dipertukarkan dan tidak boleh disajikan sebagai satu kesalahan yang tidak dapat dibedakan.
Panduan SVG BIMI Group menjelaskan SVG Portable/Secure sebagai profil yang lebih ketat dari SVG Tiny 1.2. Halaman yang dipertahankan berasal dari tahun 2020 dan diambil untuk koleksi sumber naskah ini pada tanggal 8 November 2026. Ini adalah panduan praktis kelompok, bukan klaim bahwa draf profil BIMI yang dirujuk adalah Standar Internet. Tidak ada validator yang dieksekusi di sini.
Identifikasi byte persis yang sedang ditinjau
Catat nama file kandidat, panjang byte, hash konten, sumber atau metode ekspor, dan waktu pengamatan. Jika aset berasal dari URL, pertahankan byte yang diambil daripada berasumsi byte tersebut cocok dengan file desain lokal dengan nama yang sama. Perubahan cache atau unggahan yang terjadi kemudian dapat berarti aset yang dihosting berbeda dari file yang ditinjau oleh desainer. Laporan tersebut harus menunjukkan perbedaan tersebut sebelum menyajikan temuannya.
Jangan menjalankan skrip atau mengikuti referensi eksternal hanya untuk memeriksa SVG yang tidak tepercaya. Validator defensif harus mengurai dan menganalisis aset dalam lingkungan aman yang disetujui. Artikel ini tidak menentukan implementasi parser tertentu atau mengklaim bahwa alat bernama memberikan perlindungan tersebut. Ini mendefinisikan persyaratan yang harus diverifikasi sebelum validator dipercaya dengan aset sebenarnya.
Pisahkan sintaks dasar dari profil BIMI
Sebuah file dapat berupa XML yang valid dan valid dalam model SVG yang luas namun tetap gagal memenuhi profil BIMI yang diinginkan. Panduan grup mengidentifikasi nilai yang diperlukan seperti versi 1.2 dan baseProfile tiny-ps, dan memerlukan elemen judul. Ini juga menjelaskan batasan pada referensi eksternal, skrip, animasi, dan atribut x atau y tingkat root. Validator harus melaporkan elemen atau atribut yang terlibat dan aturan sumber, bukan hanya mencatat bahwa browser dapat merender file.
Mengubah ekstensi nama file menjadi svg atau membungkus bitmap dalam wadah SVG tidak menetapkan kepatuhan profil. Panduan pemecahan masalah SVG BIMI Group membahas citra raster yang tertanam dan masalah umum lainnya. Laporan tersebut harus menjelaskan masalah struktural dan mengarahkan perancang ke sumber vektor yang disetujui atau koreksi ekspor tanpa mengklaim bahwa konversi otomatis apa pun mempertahankan karya seni merek yang diinginkan.
Pertahankan kekuatan kebutuhan dan cakupan penerima
Panduan kelompok merekomendasikan agar aset tetap kecil dan tidak melebihi 32 kilobyte; panduan ini juga merekomendasikan elemen deskripsi untuk aksesibilitas dibandingkan menjadikan elemen tersebut diwajibkan secara universal dalam panduan yang dikutip. Validator harus membedakan kegagalan yang diperlukan dari rekomendasi. Mengubah setiap rekomendasi menjadi kesalahan fatal dapat menyesatkan pengguna seperti halnya menerima elemen terlarang secara diam-diam.
Dokumentasi penyiapan BIMI Google menambahkan persyaratan dan rekomendasi khusus penerima, termasuk tinggi dan lebar minimum 96 piksel dalam panduan logo yang didokumentasikan. Itu adalah aturan dalam cakupan Google. Validator harus mengidentifikasi apakah validator sedang memeriksa profil grup, panduan kelayakan Google, atau keduanya, dan tidak boleh melabeli setiap kondisi khusus penerima sebagai persyaratan SVG universal.
Jadikan temuan dapat ditindaklanjuti tanpa secara diam-diam mengubah maknanya
Untuk setiap temuan, catat pengidentifikasi aturan atau bagian sumber, tingkat keparahan, lokasi di aset, nilai yang diamati, kondisi yang diharapkan, dan usulan perbaikan. Remediasi harus menjelaskan perubahan yang diinginkan daripada mengedit file secara diam-diam dan menyebutnya sebagai perbaikan. Menghapus referensi, mengubah teks menjadi jalur, atau mengubah geometri dapat mengubah makna visual dan memerlukan tinjauan desain yang sesuai.
Jika alat tersebut menawarkan perbaikan otomatis, perlakukan aset yang diperbaiki sebagai kandidat baru dengan hash dan temuannya sendiri. Simpan yang asli dan tunjukkan perubahan yang sebenarnya. Perbaikan tersebut tidak boleh menambahkan klaim hukum tentang kepemilikan logo atau kelayakan sertifikat. Tidak ada perbaikan otomatis, pembuatan gambar, atau transformasi aset yang dilakukan untuk naskah ini, dan tidak ada keluaran validator bersih yang diberikan.
Jaga penampilan dan aksesibilitas sebagai tinjauan terpisah
File yang valid secara struktural masih sulit dikenali dalam avatar kecil, memiliki kontras yang buruk, atau menyertakan judul yang tidak membantu. Tinjauan visual harus menilai konteks tampilan yang diinginkan, sedangkan tinjauan aksesibilitas harus memeriksa deskripsi dan presentasi tekstual yang relevan. Keduanya tidak dapat disimpulkan hanya dari skema atau profil. Laporan alat harus menandai tinjauan ini sebagai terbuka sampai ada bukti nyata.
Jangan berjanji bahwa penerima tertentu akan merender file persis seperti pratinjau lokal. Perilaku tampilan penerima, pemangkasan, dan kelayakan dapat berbeda. Pratinjau hanyalah bukti dari lingkungan pratinjau tersebut. Catatan penerimaan akhir harus mengidentifikasi penyaji atau klien mana yang diamati dan menghindari perluasan hasil ke semua penyedia kotak surat tanpa dukungan.
Verifikasi aset yang dihosting secara terpisah
Katalog memerlukan pengambilan HTTPS publik dengan konten dan bukti sertifikat selain temuan kandidat dan validator. Pengambilan tersebut harus mengidentifikasi titik akhir yang diminta, status respons, konten yang diamati, byte atau hash, stempel waktu, dan hasil validasi TLS . Ini harus menentukan apakah byte yang dihosting adalah aset yang ditinjau, bukan hanya apakah browser menunjukkan sesuatu yang serupa secara visual.
Validasi transport HTTPS berbeda dari a VMC atau CMC dikaitkan dengan logo tersebut. Panduan penyiapan Google memerlukan hosting HTTPS dan menjelaskan file bukti tanda yang didukung, namun sertifikat hosting yang valid tidak membuktikan persetujuan penerbit atas logo tersebut. Pertahankan kedua batasan dalam catatan penerimaan. Tidak ada titik akhir publik yang diambil untuk suatu aset di sini, dan tidak ada bukti koneksi TLS yang diklaim.
Lembar kerja temuan validator
Buat lembar kerja dengan hash kandidat, sumber dan versi kumpulan aturan, versi parser atau validator, setiap temuan, pemilik remediasi, dan status tinjauan. Tambahkan baris terpisah untuk validitas struktural, persyaratan profil, kondisi khusus penerima, rekomendasi, tinjauan visual, dan aksesibilitas. Bagian aset yang dihosting harus menghubungkan bukti pengambilan dan menyatakan apakah hashnya cocok dengan kandidat yang disetujui.
Gunakan perlengkapan yang terkontrol untuk kandidat yang bersih dan kegagalan yang dipilih, namun jangan mengarang hasilnya. Pengujian harus menunjukkan temuan yang diharapkan dan hasil aktual yang diperoleh, termasuk kasus yang tidak dapat dinilai oleh validator. Jika suatu persyaratan memerlukan penilaian manusia, beri label seperti itu daripada memberikan izin otomatis. Lembar kerja yang diusulkan di sini masih belum diisi dengan bukti aset asli.
Diagnosis fiktif: pembungkus raster yang ramah browser
Seorang desainer fiksi mengekspor file yang dibuka dengan benar di browser tetapi berisi data bitmap yang tertanam. Tim berasumsi bahwa pratinjau berhasil berarti logo siap untuk BIMI . Tinjauan validator yang diusulkan mengidentifikasi bahwa panduan profil yang relevan tidak menerima struktur tersebut dan menjelaskan persyaratan yang gagal daripada menyalahkan masalah tampilan yang tidak ditentukan.
Perancang akan kembali ke sumber vektor yang disetujui dan mengajukan kandidat baru untuk tinjauan struktural dan visual. Tim kemudian akan memverifikasi byte yang dihosting dan bukti HTTPS secara terpisah. Skenario ini bersifat fiktif: tidak ada aset yang dibuat, dikonversi, diunggah, atau divalidasi. Hal ini mengilustrasikan bagaimana temuan berguna menghubungkan batasan teknis dengan langkah aman berikutnya tanpa tampilan penerima yang menjanjikan.
Melepaskan hanya dengan membawa bukti aset asli
Katalog memerlukan aset kandidat, temuan validator, dan pengambilan HTTPS publik dengan konten dan bukti sertifikat. Ketiganya tetap terbuka. Tinjauan spesialis manusia, penerapan sumber, jalur produksi, aksesibilitas, dan pelepasan pemilik juga tetap terbuka. Draf ini menjelaskan perilaku validator yang diusulkan dan diagnosis fiktif, bukan alat yang berfungsi atau fitur EmailAuth yang diuji.