XML özelliğine karşı XML öğesi

İş yerinde, başka bir çevrimdışı uygulamaya veri aktarmak için XML dosyaları oluşturmamız isteniyor ve bu da, bazı verilerimizi güncellemek için geri dönmek için ikinci bir XML dosyası oluşturacak. İşlem sırasında diğer uygulamanın ekibiyle XML dosyasının yapısı hakkında görüşüyoruz.

Geldiğim örnek aslında şöyle bir şey:

<INVENTORY>
   <ITEM serialNumber="something" location="something" barcode="something">
      <TYPE modelNumber="something" vendor="something"/> 
   </ITEM>
</INVENTORY>

Diğer ekip bunun endüstri standardı olmadığını ve niteliklerin yalnızca meta veriler için kullanılması gerektiğini söyledi. Onlar önerdi:

<INVENTORY>
   <ITEM>
      <SERIALNUMBER>something</SERIALNUMBER>
      <LOCATION>something</LOCATION>
      <BARCODE>something</BARCODE>
      <TYPE>
         <MODELNUMBER>something</MODELNUMBER>
         <VENDOR>something</VENDOR>
      </TYPE>
   </ITEM>
</INVENTORY>

İlk önerme nedeni, oluşturulan dosyanın boyutunun çok daha küçük olmasıdır. Aktarım sırasında yaklaşık 80000 öğe olacaktır. Gerçekte önerileri önerdiğimden üç kat daha büyük. Bahsedilen gizemli "Endüstri Standardı" nı aradım, ancak bulabildiğim en yakın şey XML özniteliklerinin yalnızca meta veriler için kullanılması gerektiğiydi, ancak tartışmanın aslında meta verilerle ilgili olduğunu söyledi.

Uzun açıklamadan sonra (üzgünüm) meta verilerin ne olduğunu nasıl belirlersiniz ve bir XML belgesinin yapısını tasarlarken bir özniteliği veya öğeyi ne zaman kullanacağınıza nasıl karar vermelisiniz?

Bu başparmak kuralını kullanıyorum:

1. Bir Öznitelik, kendine yeten bir şeydir, yani bir renk, bir kimlik, bir ad.
2. Bir Öğe, kendi özniteliklerine sahip olan veya sahip olabilen veya başka öğeler içeren bir şeydir.

Yani seninki yakın. Ben böyle bir şey yapardı:

EDIT : Orijinal örneği aşağıdaki geri bildirime dayanarak güncelledi.

  <ITEM serialNumber="something">
      <BARCODE encoding="Code39">something</BARCODE>
      <LOCATION>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

Özniteliklerle ilgili sorunlardan bazıları şunlardır:

• öznitelikler birden fazla değer içeremez (alt öğeler içerebilir)
• özellikler kolayca genişletilemez (gelecekteki değişiklikler için)
• öznitelikler yapıları tanımlayamaz (alt öğeler olabilir)
• özniteliklerin program koduyla değiştirilmesi daha zordur
• özellik değerlerinin DTD'ye karşı test edilmesi kolay değildir

Nitelikleri veriler için kapsayıcı olarak kullanırsanız, okunması ve bakımı zor olan belgeler elde edersiniz. Verileri tanımlamak için öğeleri kullanmaya çalışın. Nitelikleri yalnızca verilerle ilgili olmayan bilgiler sağlamak için kullanın.

Bu şekilde bitirmeyin (XML bu şekilde kullanılmamalıdır):

<note day="12" month="11" year="2002" 
      to="Tove" to2="John" from="Jani" heading="Reminder"  
      body="Don't forget me this weekend!"> 
</note>

Kaynak: http://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp

"XML", "eXtensible Markup Language" anlamına gelir . Bir biçimlendirme dili, verilerin metin veya yapı veya biçimlendirme hakkında meta verilerle işaretlenmiş olduğunu belirtir .

XHTML, amaçlandığı şekilde kullanılan bir XML örneğidir:

<p><span lang="es">El Jefe</span> insists that you
    <em class="urgent">MUST</em> complete your project by Friday.</p>

Burada, elemanlar ve nitelikler arasındaki ayrım açıktır. Metin öğeleri tarayıcıda görüntülenir ve özellikler, bunların nasıl görüntüleneceğine ilişkin talimatlardır (bu şekilde çalışmayan birkaç etiket olmasına rağmen).

XML bir biçimlendirme dili olarak değil, "veri" ve "meta veri" arasındaki ayrımın daha belirsiz olduğu bir veri serileştirme dili olarak kullanıldığında karışıklık ortaya çıkar . Bu nedenle, unsurlar ve nitelikler arasındaki seçim , niteliklerle temsil edilemeyen şeyler dışında az ya da çok keyfidir (bkz. Feenster'ın cevabı).

XML Öğesi ve XML Özelliği

XML tamamen anlaşmayla ilgilidir. Öncelikle topluluğunuz veya endüstrinizdeki mevcut XML şemalarına veya belirlenmiş sözleşmelere erteleyin.

Şemanızı sıfırdan itibaren gerçekten tanımlayacak bir durumdaysanız, öğeyi nitelik kararına veya nitelik kararına bildirmesi gereken bazı genel hususlar şunlardır :

<versus>
  <element attribute="Meta content">
    Content
  </element>
  <element attribute="Flat">
    <parent>
      <child>Hierarchical</child>
    </parent>
  </element>
  <element attribute="Unordered">
    <ol>
      <li>Has</li>
      <li>order</li>
    </ol>
  </element>
  <element attribute="Must copy to reuse">
    Can reference to re-use
  </element>
  <element attribute="For software">
    For humans
  </element>
  <element attribute="Extreme use leads to micro-parsing">
    Extreme use leads to document bloat
  </element>
  <element attribute="Unique names">
    Unique or non-unique names
  </element>
  <element attribute="SAX parse: read first">
    SAX parse: read later
  </element>
  <element attribute="DTD: default value">
    DTD: no default value
  </element>
</versus>

Kullanımınıza bağlı olabilir. Bir veritabanından oluşturulan veriyi temsil etmek için kullanılan XML, sonuçta alan değerleri öznitelik olarak yerleştirilerek iyi çalışabilir.

Ancak, ileti aktarımı olarak kullanılan XML genellikle daha fazla öğe kullanıldığında daha iyi olur.

Örneğin, cevapta önerilen bu XML'ye sahip olduğumuzu varsayalım: -

<INVENTORY>
   <ITEM serialNumber="something" barcode="something">
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
    </ITEM>
</INVENTORY>

Şimdi ITEM öğesini barkod yazdıracak bir cihaza göndermek istiyoruz, ancak bir kodlama türü seçeneği var. Gerekli kodlama türünü nasıl temsil ediyoruz? Aniden, biraz gecikmiş bir şekilde, barkodun tek bir otomatik değer olmadığını, ancak basıldığında gerekli olan kodlamaya uygun olabileceğini fark ediyoruz.

   <ITEM serialNumber="something">
      <barcode encoding="Code39">something</barcode>
      <Location>XYX</LOCATION>
      <TYPE modelNumber="something">
         <VENDOR>YYZ</VENDOR>
      </TYPE>
   </ITEM>

Asıl nokta, yapıyı taşa sabitlemek için bir ad alanı ile birlikte bir tür XSD veya DTD inşa etmedikçe, seçeneklerinizi açık bırakarak en iyi şekilde servis edilebilir.

IMO XML, mevcut kodu kullanmadan esnediğinde en kullanışlıdır.

Şema tasarımımda özniteliklere ve öğelere ilişkin aşağıdaki yönergeleri kullanıyorum:

• Uzun süre çalışan metinler için öğeleri kullanın (genellikle dize veya normalize edilmiş olanlar)
• Bir öğe için iki değerin gruplanması (örn. EventStartDate ve eventEndDate) varsa nitelik kullanmayın. Önceki örnekte, "event" için startDate ve endDate özniteliklerini içerebilecek yeni bir öğe olmalıdır.
• İş Tarihi, DateTime ve sayılar (örn. Sayımlar, tutar ve oran) öğeler olmalıdır.
• Son güncelleme, son kullanma tarihi gibi iş dışı zaman öğelerinin nitelikler olması gerekir.
• Karma kodlar ve indeksler gibi ticari olmayan numaralar nitelik olmalıdır. * Tür karmaşık olacaksa öğeleri kullanın.
• Değer basit bir türse ve yinelenmiyorsa öznitelikleri kullanın.
• xml: id ve xml: lang, XML şemasına başvuruda bulunan özellikler olmalıdır
• Teknik olarak mümkün olduğunda özellikleri tercih edin.

Özelliklerin tercihi aşağıdakileri sağlamasıdır:

• benzersiz (özellik birden çok kez görünemez)
• sipariş önemli değil
• yukarıdaki özellikler devralınabilir (bu, "tüm" içerik modelinin geçerli şema dilinde desteklemediği bir şeydir)
• bonus, daha az ayrıntılı olmaları ve daha az bant genişliği kullanmalarıdır, ancak bu, unsurlara göre nitelikleri tercih etmenin bir nedeni değildir.

Teknik olarak mümkün olduğunda ekledim çünkü niteliklerin kullanımının mümkün olmadığı zamanlar var. Örneğin, öznitelik kümesi seçenekleri. Örneğin, geçerli şema dili ile (startDate ve endDate) xor (startTS ve endTS) kullanmak mümkün değildir

XML Şeması "tüm" içerik modelinin kısıtlanmasına veya genişletilmesine izin verirse, büyük olasılıkla bırakırım

Şüphe duyduğunuzda , KISS - özellikleri kullanmak için net bir nedeniniz olmadığında neden özellikleri ve öğeleri karıştırın. Daha sonra bir XSD tanımlamaya karar verirseniz, bu da daha temiz olur. Daha sonra XSD'nizden bir sınıf yapısı oluşturmaya karar verirseniz, bu da daha basit olacaktır.

Bu sorunun evrensel bir cevabı yok (W3C spesifikasyonunun yaratılmasına yoğun bir şekilde dahil oldum). XML birçok amaç için kullanılabilir - metin benzeri belgeler, veriler ve bildirim kodu en yaygın üçüdür. Veri modeli olarak da çok kullanıyorum. Bu uygulamaların niteliklerin daha yaygın olduğu yönleri ve alt öğelerin daha doğal olduğu yönleri vardır. Ayrıca, bunları kullanmayı kolaylaştıran veya zorlaştıran çeşitli araçların özellikleri de vardır.

XHTML, niteliklerin doğal bir kullanıma sahip olduğu bir alandır (örn. Class = 'foo'). Özniteliklerin düzeni yoktur ve bu bazı kişilerin araç geliştirmesini kolaylaştırabilir. OTOH özniteliklerinin şema olmadan yazılması daha zordur. Ayrıca ad boşluklu öznitelikleri (foo: bar = "zork") çeşitli araç setlerinde yönetmek genellikle daha zordur. Ancak yaygın olan karışımı görmek için bazı W3C dillerine bir göz atın. SVG, XSLT, XSD, MathML iyi bilinen dillerin bazı örnekleridir ve hepsinin zengin nitelikleri ve unsurları vardır. Bazı diller, birden fazla yolla bunu bile yapabilir, örn.

<foo title="bar"/>;

veya

<foo>
  <title>bar</title>;
</foo>;

Bunların sözdizimsel olarak eşdeğer OLMADIĞINI ve işleme araçlarında açık destek gerektirdiğini unutmayın)

Tavsiyem, uygulamanıza en yakın alanda ortak uygulamaya bakmak ve hangi araç setlerini uygulamak isteyebileceğinizi düşünmektir.

Son olarak, ad alanlarını özniteliklerden ayırdığınızdan emin olun. Bazı XML sistemleri (ör. Linq), ad alanlarını API'daki özellikler olarak temsil eder. IMO bu çirkin ve potansiyel olarak kafa karıştırıcı.

Diğerleri, öznitelikler arasında öğelerden nasıl ayırt edileceğini, ancak daha genel bir perspektiften, her şeyi niteliklere koyarak, sonuçta ortaya çıkan XML'yi daha küçük hale getirdiğini açıklamıştır.

XML, kompakt değil taşınabilir ve insan tarafından okunabilir olacak şekilde tasarlanmıştır. Aktarılan verilerin boyutunu azaltmak istiyorsanız, başka bir şey kullanın ( google'ın protokol tamponları gibi ).

milyon dolarlık soru!

Öncelikle, şimdi performans hakkında çok fazla endişelenme. optimize edilmiş bir xml ayrıştırıcısının xml'nizi ne kadar hızlı parçalayacağına şaşıracaksınız. daha da önemlisi, gelecek için tasarımınız nedir: XML geliştikçe, gevşek bağlantıyı ve birlikte çalışabilirliği nasıl koruyacaksınız?

daha somut olarak, bir öğenin içerik modelini daha karmaşık hale getirebilirsiniz, ancak bir özelliği genişletmek daha zordur.

Nesnenin özelliklerini depolamak için her iki yöntem de mükemmel şekilde geçerlidir. Pragmatik değerlendirmelerden ayrılmalısınız. Aşağıdaki soruyu cevaplamayı deneyin:

1. Hangi gösterim daha hızlı veri ayrıştırma \ oluşturulmasına yol açar?

2. Hangi gösterim daha hızlı veri aktarımına yol açar?

3. Okunabilirlik önemli mi?

   ...

Veriler için öğeleri ve meta veriler için öznitelikleri (öğenin verileri hakkındaki veriler) kullanın.

Bir öğe, seçim dizelerinizde bir yüklem olarak görünüyorsa, bunun bir özellik olması gerektiği konusunda iyi bir işaretiniz vardır. Benzer şekilde, bir özellik hiçbir zaman yüklem olarak kullanılmazsa, belki de yararlı meta veriler değildir.

XML'in insan tarafından okunamayan makine tarafından okunabilir olması gerektiğini ve büyük belgeler için XML'nin çok iyi sıkıştırdığını unutmayın.

Her iki şekilde de tartışılabilir, ancak iş arkadaşlarınız, XML'in gerçek verilerin etrafında "işaretleme" veya meta veriler için kullanılması gerektiği anlamındadır. Sizin açınızdan, XML'de alanınızı modellerken meta veriler ve veriler arasındaki çizginin nerede olduğuna karar vermek bazen zor olabilir. Uygulamada, yaptığım şey, işaretlemedeki herhangi bir şeyin gizli olduğunu ve yalnızca işaretlemenin dışındaki verilerin okunabilir olduğunu iddia etmektir. Belge bu şekilde bir anlam ifade ediyor mu?

XML herkesin bildiği gibi hantal. Taşıma ve depolama için, işlem gücünü göze alabiliyorsanız sıkıştırma önerilir. XML, tekrarlanabilirliği nedeniyle iyi, bazen olağanüstü iyi bir şekilde sıkıştırır. Orijinal boyutlarının% 5'inden daha azına sıkıştırılan büyük dosyalar yaşadım.

Konumunuzu desteklemenin bir başka noktası, diğer takım stil hakkında tartışırken (çoğu XML aracının bir all-attribute belgesini bir all- # PCDATA belgesi kadar kolay işleyeceği şekilde) pratiklikleri tartıştığınızdır. Stil tamamen göz ardı edilemezken, teknik değerler daha fazla ağırlık taşımalıdır.

Bu büyük ölçüde bir tercih meselesi. Gruplama için Elements ve mümkün olan yerlerde veri için öznitelikler kullanıyorum çünkü bunu alternatiften daha kompakt görüyorum.

Mesela ben tercih ederim .....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
         <person name="Rory" surname="Becker" age="30" />
        <person name="Travis" surname="Illig" age="32" />
        <person name="Scott" surname="Hanselman" age="34" />
    </people>
</data>

...Onun yerine....

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person>
            <name>Rory</name>
            <surname>Becker</surname>
            <age>30</age>
        </person>
        <person>
            <name>Travis</name>
            <surname>Illig</surname>
            <age>32</age>
        </person>
        <person>
            <name>Scott</name>
            <surname>Hanselman</surname>
            <age>34</age>
        </person>
    </people>
</data>

Bununla birlikte, 20-30 karakter arasında kolayca temsil etmeyen veya birçok tırnak işareti veya kaçması gereken diğer karakterler içeren verilerim varsa, o zaman öğeleri ayırmanın zamanı geldiğini söyleyebilirim ... muhtemelen CData bloklarıyla.

<?xml version="1.0" encoding="utf-8"?>
<data>
    <people>
        <person name="Rory" surname="Becker" age="30" >
            <comment>A programmer whose interested in all sorts of misc stuff. His Blog can be found at http://rorybecker.blogspot.com and he's on twitter as @RoryBecker</comment>
        </person>
        <person name="Travis" surname="Illig" age="32" >
            <comment>A cool guy for who has helped me out with all sorts of SVn information</comment>
        </person>
        <person name="Scott" surname="Hanselman" age="34" >
            <comment>Scott works for MS and has a great podcast available at http://www.hanselminutes.com </comment>
        </person>
    </people>
</data>

Zor kazanılmış nesne yönelimi sezgimizden faydalanmaya ne dersiniz? Genellikle hangi nesnenin, hangi nesnenin bir özniteliği veya hangi nesneye atıfta bulunduğunu düşünmenin doğru olduğunu düşünüyorum.

Nesneler olarak sezgisel olarak hangisi mantıklıysa, eleman olarak sığmalıdır. Öznitelikleri (veya özellikleri), xml veya niteliğe sahip alt öğedeki bu öğelerin öznitelikleri olacaktır.

Örnek nesne yönelimi benzetmesi gibi daha basit durumlar için hangi elemanın ve hangi elemanın niteliği olduğunu anlamaya çalışır.

Bazı kötü bilgiler için sadece birkaç düzeltme:

@John Ballinger: Özellikler herhangi bir karakter verisi içerebilir. <> & "'sırasıyla & lt; & amp; & quot; ve & amp; & # 39; & amp; & quot; ve & apos; kaçması gerekir.XML kütüphanesi kullanırsanız, bu sizin için halledecektir.

Cehennem, bir öznitelik, isterseniz, yalnızca base64 kodlayarak ve bir veri: URL yaparak görüntü gibi ikili veriler içerebilir.

@feenster: Nitelikler, IDS veya NAMES durumunda boşluk içeren, sayı içeren birden fazla öğe içerebilir. Nitpicky, ama bu yerden tasarruf sağlayabilir.

Öznitelikleri kullanmak XML'yi JSON ile rekabetçi tutabilir. Bkz. Yağ İşaretleme: Yağ İşaretleme Efsanesini her seferinde bir kalori kesme .

Bu tür tartışmaların sonuçları beni her zaman şaşırtıyor. Bana göre, verilerin bir öznitelikte mi yoksa içerik olarak mı olduğuna karar vermek için çok basit bir kural vardır ve bu da verilerin gezilebilir alt yapıya sahip olup olmadığına karar verir.

Örneğin, biçimlendirilmemiş metin her zaman niteliklere aittir. Her zaman.

Listeler alt yapıya veya içeriğe aittir. Zaman içinde gömülü yapılandırılmış alt içeriği içerebilen metinler içeriğe aittir. (Deneyimlerime göre, XML veri depolama veya değişim için kullanılırken, bununla - işaretli metin - nispeten azdır.)

Bu şekilde yazılmış XML şeması özlüdür.

Ne zaman böyle durumlar görürsem <car><make>Ford</make><color>Red</color></car>, kendi kendime "gee yazar, make öğesi içinde alt öğeler olacağını düşünmüş müydü?" <car make="Ford" color="Red" />önemli ölçüde daha okunabilir, boşlukların nasıl ele alınacağı hakkında hiçbir soru yok.

Sadece boşluk kullanım kuralları göz önüne alındığında, bunun XML tasarımcılarının açık amacı olduğuna inanıyorum.

Nitelikler ve işaretleme farklılıklarının açıkça görülebildiği HTML'de bu çok açıktır:

1. Tüm veriler işaretleme arasında
2. Nitelikler bu verileri karakterize etmek için kullanılır (örn. Formatlar)

Yalnızca XML olarak saf verileriniz varsa, daha az net bir fark vardır. Veriler işaretleme arasında veya öznitelikler olarak durabilir.

=> Çoğu veri işaretleme arasında durmalıdır.

Burada nitelikleri kullanmak istiyorsanız: Verileri iki kategoriye ayırabilirsiniz: Veri ve meta verilerin kaydın bir parçası olmadığı "meta veriler", ancak "format sürümü", "oluşturulma tarihi" gibi şeyler , vb.

<customer format="">
     <name></name>
     ...
</customer>

Ayrıca şöyle diyebiliriz: "Etiketi karakterize etmek için nitelikleri kullanın, verilerin kendisini sağlamak için etiketleri kullanın."

Feenster ile hemfikirim. Mümkünse özelliklerden uzak durun. Unsurlar evrim dostudur ve web servis araç takımları arasında daha fazla birlikte çalışabilir. Bu araç setlerini, istek / yanıt iletilerinizi öznitelikler kullanarak serileştirirken asla bulamazsınız. Bu, mesajlarımızın bir web hizmeti araç takımı için veri (meta veri değil) olması nedeniyle de anlamlıdır.

Öznitelikleri yönetmek bana zamanla kolayca zor olabilir. Ben her zaman onlardan şahsen uzak duruyorum. Öğeler hem ayrıştırıcılar hem de kullanıcılar tarafından çok daha açık ve okunabilir / kullanılabilir.

Onları kullandığım tek zaman, bir varlık URL'sinin dosya uzantısını tanımlamaktı:

<image type="gif">wank.jpg</image> ...etc etc

% 100 biliyorsanız özellik genişletilmiş gerekmez onları kullanabilirsiniz, ama bunu kaç kez biliyorsun.

<image>
  <url>wank.jpg</url>
  <fileType>gif</fileType>
</image>