XML öğeleri için standart bir adlandırma kuralı var mı? [kapalı]


99

XML belgeleri için fiili veya başka bir standart var mı? Örneğin, bir etiket yazmanın "en iyi" yolu hangisidir?

<MyTag />
<myTag />
<mytag />
<my-tag />
<my_tag />

Aynı şekilde, daha iyi olan bir öznitelik için numaralandırılmış bir değere sahipsem

<myTag attribute="value one"/>
<myTag attribute="ValueOne"/>
<myTag attribute="value-one"/>

2
Teknik olarak <my.tag /> 'ı da kullanabilirsiniz. Bazı bağlamlarda iyi bir fikir
olmayabilir


Çevrimiçi bulunan birkaç "standart" var ..
user2864740

Yanıtlar:


47

En yaygın değerlerin camelCased olacağından şüpheleniyorum - ör.

<myTag someAttribute="someValue"/>

Özellikle, boşluklar kod oluşturucularla karıştırılırsa birkaç hataya neden olur (yani xml'yi nesnelere [de] serileştirmek için), çünkü birçok dil boşluklu numaralandırmalara izin vermez (ikisi arasında bir eşleştirme gerektirir).


36
Hm ... en iyi cevap ... Bence iyi bir cevap, ama bu sadece bir fikir. Bir çeşit referansa sahip olmak güzel olurdu.
Hamish Grubijan

4
Katılmıyorum, deve kılıfıyla XML görmeye alışkın değilim.
Rafa

Bunun eski bir cevap olduğunu biliyorum, ancak gördüğüm yeni Microsoft XML'lerin çoğu bu biçim seçimine katılmıyor. Ama sonra IIS dot.naming'i seviyor çok ..
user2246674

4
Herkesin kişisel olduğundan bahsettiği gibi, ancak XML'mi her zaman XMLSchema kullanarak tanımladığım için yaklaşımınızı takip ediyorum ve XMLSchema bu yaklaşımı izliyor. w3.org/2001/XMLSchema.xsd . Benim için programlama dilleriyle ilgisi yok. XML kullanıyoruz çünkü birlikte çalışabilir bir arayüz standardı. Programlama dilleri yalnızca bir uygulama ayrıntısıdır ve her dilin kendi kuralları vardır.
dan carter

2 sentim - CamelCase'i gördüm ve tümü küçük harf; nadiren tümü büyük (eski HTML) ve küçük harf gördüm. CamelBack'i gördüğümü hiç hatırlamıyorum. CamelCase'i veya küçük harfleri tercih ederim. Nitelikler, ancak, tümünün küçük harf olduğunu görme eğilimindeyim.
Kit10

30

XML Adlandırma Kuralları

XML öğeleri şu adlandırma kurallarına uymalıdır:

    - Element names are case-sensitive 
    - Element names must start with a letter or underscore
    - Element names cannot start with the letters xml(or XML, or Xml, etc) 
    - Element names can contain letters, digits, hyphens, underscores, and periods 
    - Element names cannot contain spaces

Herhangi bir isim kullanılabilir, hiçbir kelime ayrılmaz (xml hariç).

En İyi Adlandırma Uygulamaları

    - Create descriptive names, like this: <person>, <firstname>, <lastname>.
    - Create short and simple names, like this: <book_title> not like this: <the_title_of_the_book>.
    - Avoid "-". If you name something "first-name", some software may think you want to subtract "name" from "first".
    - Avoid ".". If you name something "first.name", some software may think that "name" is a property of the object "first".
    - Avoid ":". Colons are reserved for namespaces (more later).
    - Non-English letters like éòá are perfectly legal in XML, but watch out for problems if your software doesn't support them.

Stilleri Adlandırma

XML öğeleri için tanımlanmış bir adlandırma stili yoktur. Ancak burada yaygın olarak kullanılanlardan bazıları şunlardır:

    - Lower case    <firstname> All letters lower case
    - Upper case    <FIRSTNAME> All letters upper case
    - Underscore    <first_name>    Underscore separates words
    - Pascal case   <FirstName> Uppercase first letter in each word
    - Camel case    <firstName> Uppercase first letter in each word except the first

referans http://www.w3schools.com/xml/xml_elements.asp


13

Benim için bu, bir programlama dili için kod stilini tartışmak gibidir: bazıları bir stil için tartışır, diğerleri bir alternatifi savunur. Gördüğüm tek fikir birliği: "Bir stil seçin ve tutarlı olun"!

Pek çok XML lehçesinin sadece küçük harfli isimler kullandığını (SVG, Ant, XHTML ...) not ediyorum.

"Özellik değerlerinde boşluk yok" kuralını anlamıyorum. Her nasılsa, "niteliklere ne eklenmeli ve metin olarak ne yazılmalı?" Tartışmasına gönderiyor.
Belki bunlar en iyi örnekler değildir, ancak özniteliklerde boşluk kullanan bazı iyi bilinen XML biçimleri vardır:

  • XHTML, özellikle sınıf özniteliği (iki veya daha fazla sınıf koyabilirsiniz) ve tabii ki alt ve başlık öznitelikleri.
  • SVG, örneğin yol etiketinin d niteliğiyle.
  • Her ikisi de stil niteliğiyle ...

Uygulamaya karşı argümanları tam olarak anlamıyorum (sadece bazı kullanımlar için geçerli gibi görünüyor) ama en azından yasal ve oldukça yaygın olarak kullanılıyor. Görünüşe göre sakıncaları var.

Oh, ve otomatik kapanma eğik çizgisinden önce boşluk bırakmanıza gerek yok. :-)


Boşluklara karşı argüman şudur ve bunun nedeni yalnızca soruda özel olarak sorulmasıdır, eğer değer ayrıştırmayı desteklemek için numaralandırılırsa, pek çok dil boşluklarla numaralandırmayı desteklemez, yine de çoğumuz C / C ++, C # veya Java (kullandığım diller, ancak bunlarla sınırlı değildir) genellikle öznitelik değerlerini numaralandırmalarla eşler. Daha sonra bir kelimeyi bir haritaya / sözlüğe (veya Java ve C # durumunda daha kolay) ayrıştırabiliriz. Nihayetinde bunun bir standarttan ziyade bir ateş meselesi gibi göründüğüne katılıyorum. Ben sadece "Roma'da ne zaman" felsefesini takip ediyorum.
Kit10

12

Öğe adları için TitleCase'i ve öznitelikler için camelCase'i tercih ediyorum. İkisi için de boşluk yok.

<AnElement anAttribute="Some Value"/>

Bir kenara, XML'deki En İyi Uygulamalar için hızlı bir arama yaptım ve oldukça ilginç bir bağlantı buldum: XML şemaları: En İyi Uygulamalar .


8

Küçük harfli veya deve harfli etiketleri tercih etme eğilimindeyim ve özniteliklerin tipik olarak veri değerlerini yansıtması gerektiğinden - içeriği değil - hangi platform / dilde ilgileniyor olursa olsun değişken adı olarak kullanılabilecek bir değere bağlı kalırdım , yani boşluklardan kaçının ama diğer iki biçimi olabilir olmak ok


Değişken / işlev adlarını düşünmek için +1
Ates Goral

@downvoter: Lütfen bana kendinizi açıklama nezaketinde bulunun.
annakata

8

Bu özneldir, ancak bir öğe etiketinde iki kelime varsa, okunabilirlik <my_tag>ayırıcı kullanmak yerine kelimeler arasına bir alt çizgi eklenerek (örneğin ) geliştirilebilir. Referans: http://www.w3schools.com/xml/xml_elements.asp . Yani w3schools'a göre cevap şöyle olacaktır:

<my_tag attribute="some value">

Özellik değerlerinde boşluklara izin verildiğinden, ancak öğe etiketi adlarında izin verilmediğinden, değerin alt çizgi veya ayırıcı kullanmasına gerek yoktur.


2
+1, "En İyi Adlandırma Uygulamaları" bölümüne sahip bir referanstan alıntı yaptığınız için (sadece görüş değil)
Fuhrmanator

2
@Fuhrmanator Bu "referans", bazı gerekçeler sunsa da, kendisi bir fikirdir. Herhangi bir yöntemle bir standart değil - ve (o was çok daha az korkunç olsa bile) ben do not bir "referans" olarak tavsiye veya kullanım W3Schools. Çok daha özgün ve kapsamlı kaynaklar var.
user2864740

@ user2864740 gibi? Daha özgün ve kapsamlı kaynakları sağlamadan önce yorumunuzu bitirdiniz. + 1'imin amacı, OP'nin standartları sorması, ancak çoğu yanıtın fikir vermesiydi.
Fuhrmanator

Bu cevap sadece fikir verir , w3schools bağlantısı alakasızdır ve bunları kaldırmaz. Bildiğim kadarıyla standartları gibi, (olduğu gibi uygulama kurallarını görmek RSS (olduğu gibi) veya kuruluş kurallarını OAGi ) - Bazı düzeyde "standart" yalnızca belirli bir uygulama / iş düzeyinde uygulanır. W3schools bağlantısı yalnızca kendi fikrini / en iyi uygulamasını çok belirsiz bir şekilde sağlar (birkaç ipucu sağlar ve "işte bir şekilde bitti" der).
user2864740

Yani, yalnızca bir bağlantı eklemek, bir yanıtı (veya bağlı kaynağı) yetkili kılmaz.
user2864740

7

Belge merkezli XML lehçelerinin çoğu küçük harf temel Latin ve tire kullanır. Ben onunla gitme eğilimindeyim.

XML'yi doğrudan programlama dili tanımlayıcılarına eşleyen kod üreteçleri kırılgandır ve (XAML gibi saf nesne serileştirme dışında) taşınabilir belge biçimlerinde kaçınılmalıdır; En iyi yeniden kullanım ve bilgi uzun ömürlülüğü için XML, uygulama ile değil, etki alanıyla eşleşmeye çalışmalıdır.


3

rss, muhtemelen dünyada en çok tüketilen xml şemalarından biridir ve camelCased'dır.

Spesifikasyon burada: http://cyber.law.harvard.edu/rss/rss.html

Şemada herhangi bir düğüm özniteliği yoktur, ancak tüm düğüm öğesi adları camelCased'dır. Örneğin:

lastBuildDate managingEditor pubDate


2

Normalde XML adlandırma kuralını kodun diğer bölümlerindeki aynı adlandırma kuralına göre hizalarım. Bunun nedeni, XML'i Object'e yüklediğimde, öznitelikleri ve öğe adları, şu anda projede kullanılan aynı adlandırma kuralı olarak adlandırılabilir.

Örneğin, javascript'iniz camelCase kullanıyorsa, XML'iniz de camelCase kullanır.


1
Proje içi çalışma için yararlı olsa da, XML dilden bağımsız bir değişim biçimi olarak kullanıldığında bu hızla bozulur.
user2864740

Öyleyse projenizdeki bileşenler tutarlı, ancak projenin uyacağı başlangıç ​​standardını nasıl tasarlıyorsunuz?
Gqqnbig

2

Microsoft iki kuralı benimser:

  1. İçin yapılandırma Microsoft kullanır camelCase . Visual Studio yapılandırma dosyasına bakın. VS2013 için şu konumlarda saklanır:

    C: \ Program Dosyaları (x86) \ Microsoft Visual Studio 12.0 \ Common7 \ IDE \ devenv.exe.config

Misal:

<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
  1. Microsoft ayrıca XAML için UpperCase kullanır . Sanırım HTML'den (küçük harf kullanan) farklılaşmak için.

Misal:

<MenuItem Header="Open..." Command="ApplicationCommands.Open">
    <MenuItem.Icon>
        <Image Source="/Images/folder-horizontal-open.png" />
    </MenuItem.Icon>
</MenuItem>

1

Açıkça bir öneri yok. W3C'nin XHTML için olan diğer önerilerine dayanarak küçük harf kullanmayı seçtim:

4.2. Öğe ve öznitelik adları küçük harf olmalıdır

XHTML belgeleri, tüm HTML öğesi ve öznitelik adları için küçük harf kullanmalıdır. Bu fark gereklidir, çünkü XML büyük / küçük harfe duyarlıdır, örneğin <li> ve <LI> farklı etiketlerdir.


0

XML Adlandırma Kuralları

XML öğeleri şu adlandırma kurallarına uymalıdır:

  • İsimler harf, rakam ve diğer karakterleri içerebilir
  • İsimler bir sayı veya noktalama karakteriyle başlayamaz
  • İsimler xml (veya XML veya Xml, vb.) Harfleriyle başlayamaz
  • İsimler boşluk içeremez Herhangi bir isim kullanılabilir, hiçbir kelime ayrılmaz.

Kaynak: W3 School


Ne tür isimlerin mümkün olduğuna dair muğlak bir açıklama, olası isimlerden hangisinin kullanılması gerektiği konusunda çok az rehberlik sağlar.
Samuel Edwin Ward

Neyin mümkün olabileceğinin temelini tanımlasalar da - değil mi?
petermeissner

10
Elbette, ama bu, birisi "çocuğuma ne isim vermeliyim ki okulda seçilmesin" diye sorması ve siz "iyi, işte insanların üretebileceği seslerin bir listesi."
Samuel Edwin Ward

Evet, ama aslında soru htat değildi, değil mi? Çünkü sorular şuydu: "XML öğeleri için standart bir adlandırma kuralı var mı?" ve "XML belgeleri için fiili veya başka bir standart var mı?" yani bu bir cevap değil mi? Soruyu yanıtlayan ve sorunun tek bir ortak yorumlama akışı değil.
petermeissner

3
Bu sadece iki cümleden sonra sorunun geri kalanını görmezden gelirseniz bir cevaptır. "Hangisi" "en iyisi" veya "hangisi daha iyi" yanıtını vermeye çalışmadınız.
Samuel Edwin Ward

0

Çok iyi bir yaklaşım arıyordum, bu konuyu ve bazılarını da okudum ve tire kullanmak için oy verirdim .

ARIA'da ( https://developer.mozilla.org/de/docs/Web/Barrierefreiheit/ARIA ) geniş çapta kullanılırlar ve bu nedenle birçok kaynak kodunda görülür ve bu nedenle yaygındır. Burada daha önce belirtildiği gibi, bunlara kesinlikle izin verilir, bu da burada açıklanmaktadır: XML öğesi adında - kullanımı

Ayrıca bir yan fayda olarak: CSS ile birlikte HTML yazarken, genellikle adları ayırıcı olarak tireleri varsayılan olarak kullanan sınıflarınız olur. Şimdi, CSS sınıflarını veya CSS sınıflarını kullanan etiketler için özel öznitelikleri kullanan özel etiketleriniz varsa, şuna benzer bir şey:

<custom-tag class="some-css-class">

daha tutarlı ve okur - alçakgönüllü görüşüme göre - çok daha güzel:

<customTag class="some-css-class">

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.