it-swarm.dev

Jaké jsou nejlepší postupy pro navrhování schémat XML?

Jako amatérský softwarový vývojář (jsem stále v akademické sféře) jsem napsal několik schémat pro dokumenty XML. I běžně běžet do designu flubs, které způsobují ošklivě vypadající XML dokumenty, protože nejsem zcela jistý, co sémantika XML přesně jsou.

Moje předpoklady:

<property> value </property>

property = hodnota

<property attribute="attval"> value </property>

Vlastnost se speciálním deskriptorem, atributem.

<parent>
  <child> value </child>
</parent>

Rodič má charakteristiku "dítě", která má hodnotu "hodnota".

<tag />

"Tag" je příznak nebo se přímo převádí na text. Nejsem si jistý v tomto.

<parent>
  <child />
</parent>

"dítě" popisuje "rodič". "child" je příznak nebo boolean. Ani si nejsem jistý.

Nejednoznačnost vzniká, pokud chcete udělat něco jako reprezentující kartézské souřadnice:

<coordinate x="0" y="1 />

<coordinate> 0,1 </coordinate>

<coordinate> <x> 0 </x> <y> 1 </y> </coordinate>

Který z nich je nejsprávnější? Chtěl bych se opřít o třetí na základě mé současné koncepce designu schématu XML, ale opravdu nevím.

Jaké jsou zdroje, které stručně popisují, jak efektivně navrhovat xml schémata?

43
evizaer
17
Dimitre Novatchev

Jedním z obecných (ale důležitých!) Doporučení není nikdy ukládat více logických částí dat do jednoho uzlu (ať už jde o textový uzel nebo uzel atributu). V opačném případě budete potřebovat vlastní logiku syntaktické analýzy na vrcholu logiky analýzy XML, kterou obvykle získáte z vašeho rámce.

Takže ve vašem příkladě souřadnic jsou mi rozumné <coordinate x="0" y="1" /> A <coordinate> <x>0</x> <y>1</y> </coordinate> .

<coordinate> 0,1 </coordinate> ale není moc dobré, protože ukládá dvě logická data (souřadnici X a souřadnici Y) do jediného uzlu XML - což nutí spotřebitele analyzovat data mimo jejich XML analyzátor. A zatímco rozdělení řetězce čárkou je velmi jednoduché, stále existují určité nejasnosti, jako je to, co se stane, když je na konci extra čárka.

23
C. Dragon 76

Souhlasím s radou w/cdragon níže, abyste se vyhnuli možnosti # 2. Volba mezi # 1 a # 3 je do značné míry otázkou stylu. Rád používám atributy pro to, co považuji za atributy entity, a prvky pro to, co považuji za data. Někdy je těžké klasifikovat. Nicméně ani jeden není "špatný".

A zatímco se zabýváme tématem návrhu schémat, přidám své dva centy týkající se mé upřednostňované úrovně (maximálního) opětovného použití (obou prvků a typů), což může také usnadnit externí "logické" odkazování těchto entit na, datový slovník uložený v databázi. 

Povšimněte si, že zatímco vzor schématu „Zahrada Eden“ nabízí maximální opakované použití, zahrnuje také většinu práce. Ve spodní části tohoto příspěvku jsem poskytl odkazy na další vzory obsažené v sérii blogů.

• Přístup zahrady Eden  http://blogs.msdn.com/skaufman/archive/2005/05/10/416269.aspx

Používá modulární přístup definováním všech prvků globálně a podobně jako Benátský Blind přístup jsou všechny definice typů deklarovány globálně. Každý prvek je globálně definován jako bezprostřední potomek uzlu a jeho typový atribut lze nastavit na jeden z pojmenovaných komplexních typů.

<?xml version="1.0" encoding="UTF-8"?> 
<xs:schema targetNamespace="TargetNamespace" xmlns:TN="TargetNamespace" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  elementFormDefault="qualified" attributeFormDefault="unqualified"/> 
<xs:element name="BookInformation" type="BookInformationType"/> 
  <xs:complexType name="BookInformationType"/> 
    <xs:sequence> 
      <xs:element ref="Title"/> 
      <xs:element ref="ISBN"/> 
      <xs:element ref="Publisher"/> 
      <xs:element ref="PeopleInvolved" maxOccurs="unbounded"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:complexType name="PeopleInvolvedType"> 
    <xs:sequence> 
      <xs:element name="Author"/> 
    </xs:sequence> 
  </xs:complexType> 
  <xs:element name="Title"/> 
  <xs:element name="ISBN"/> 
  <xs:element name="Publisher"/> 
  <xs:element name="PeopleInvolved" type="PeopleInvolvedType"/> 
</xs:schema>
Výhodou tohoto přístupu je, že schémata jsou opakovaně použitelná. Vzhledem k tomu, že oba prvky a typy jsou definovány globálně, obě jsou k dispozici pro opětovné použití. Tento přístup nabízí maximální množství opakovaně použitelného obsahu. Nevýhodou je to, že schéma je podrobné. Toto by byl vhodný design při vytváření obecné knihovny, ve kterých si můžete dovolit provádět žádné předpoklady o rozsahu prvků a typů schémat a jejich použití v jiných schématech, zejména s ohledem na rozšiřitelnost a modularitu.


Protože každý odlišný typ a prvek má jednu globální definici, tyto kanonické částice/komponenty mohou být vztaženy k jednotlivým identifikátorům v databázi. A i když to může na první pohled vypadat jako únavné pokračující ruční úkol udržet asociace mezi textovými XSD částicemi/komponentami a databází, SQL Server 2005 může ve skutečnosti generovat identifikátory komponent kanonického schématu pomocí příkazu 

CREATE XML SCHEMA COLLECTION

http://technet.Microsoft.com/en-us/library/ms179457.aspx

Naopak, pro konstrukci schématu z kanonických částic poskytuje SQL Server 2005 

SELECT xml_schema_namespace function

http://technet.Microsoft.com/en-us/library/ms191170.aspx

ca · non · i · cal Vztahuje se k matematice. (rovnice, souřadnice, atd.) "v nejjednodušším nebo standardním tvaru" http://dictionary.reference.com/browse/canonical

Další, jednodušší konstrukce, ale méně resuable/více "denormalized/redundantní" schémata zahrnují

• Přístup ruské panenky http://blogs.msdn.com/skaufman/archive/2005/04/21/410486.aspx

Schéma má jeden globální prvek - kořenový prvek. Všechny ostatní elementy a typy jsou vnořeny postupně hlouběji, což mu dává jméno, protože každý typ se vejde do jednoho nad ním. Protože prvky v tomto návrhu jsou deklarovány lokálně, nebudou znovu použitelné prostřednictvím importu nebo zahrnutí příkazů.

• Přístup Salami Slice  http://blogs.msdn.com/skaufman/archive/2005/04/25/411809.aspx

Všechny prvky jsou definovány globálně, ale definice typů jsou definovány lokálně. Tímto způsobem mohou ostatní prvky znovu použít. S tímto přístupem poskytuje globální prvek s lokálně definovaným typem úplný popis obsahu prvků. Tato „slice“ této informace se deklaruje individuálně a pak se spojí dohromady a může se také sestavit dohromady, aby se vytvořily další schémata.

• Benátský slepý přístup  http://blogs.msdn.com/skaufman/archive/2005/04/29/413491.aspx

Podobně jako přístup ruské panenky v tom, že oba používají jeden globální prvek. Benátský Blind přístup popisuje modulární přístup pojmenováním a definováním všech definic typu globálně (na rozdíl od přístupu Salami Slice, který deklaruje elementy globálně a typy lokálně). Každý globálně definovaný typ popisuje jednotlivé "lamely" a může být znovu použit jinými komponenty. Navíc všechny lokálně deklarované elementy mohou být kvalifikovány jmenným prostorem nebo jmenným prostorem bez výhrad (lamely mohou být "otevřeny" nebo "uzavřeny") v závislosti na nastavení atributu elementFormDefault v horní části schématu.

11
6eorge Jetson

XML je poněkud subjektivní, co se týče designu - nemyslím si, že existují přesné pokyny, jak by měly být prvky a atributy vyloženy, ale mám tendenci jít s použitím prvků, které představují „věci“ a atributy, které představují jednotlivé atributy/vlastnosti z nich. 

Pokud jde o příklad souřadnic, buď by to bylo naprosto přijatelné, ale mým sklonem by bylo jít s <coordinate x="" y=""/>, protože je to poněkud poněkud strmější a dokument je o něco srozumitelnější, pokud jich máte mnoho.

Nejdůležitější věcí je však jmenný prostor schématu. Ujistěte se, že (a) máte jeden, a (b) máte tam verzi, takže můžete v budoucnu měnit věci a vydávat novou verzi. Verze mohou být buď data nebo čísla, např.

http://company.com/2008/12/something/somethingelse/
urn:company-com:2008-12:something:somethingelse

http://company.com/v1/something/somethingelse/
urn:company-com:v1:something:somethingelse
3
Greg Beech

Nevím žádné dobré studijní zdroje o tom, jak navrhovat XML modely dokumentů (schémata jsou jen formálním způsobem, jak určit modely dokumentů).

Podle mého názoru je jedním z klíčových pohledů na XML to, že to není jazyk: je to syntaxe. Každý model dokumentu je samostatný jazyk.

Různé kultury budou každý používat XML svým vlastním zvláštním způsobem. I ve specifikacích W3C můžete cítit LISP v pomlčkách oddělených pomlčkami XSLT a Java v schématu camelCaseNames XML Schema. Podobně budou různé aplikační domény vyžadovat různé XML idiomy.

Modely narativních dokumentů jako HTML nebo DocBook mají tendenci vkládat tisknutelný text do textových uzlů a metadat do názvů prvků a atributů.

Více objektově orientovaných modelů dokumentů, jako je SVG , nevyužívá textových uzlů nebo používá pouze prvky a atributy.

Moje osobní pravidla pro návrh modelu dokumentu jdou něco takového:

  • Pokud se jedná o druh volně dostupné polévky, která vyžaduje smíšený obsah , použijte jako zdroj inspirace HTML a DocBook. Ostatní pravidla jsou relevantní pouze jinak.
  • Pokud bude hodnota složená nebo hierarchická, použijte prvky. Data XML by neměla vyžadovat žádné další analýzy, s výjimkou zavedených idiomů, jako jsou například IDREFS, což jsou jednoduché prostorově oddělené sekvence.
  • Pokud hodnota může být nutné provést více než jednou, použijte prvky.
  • Pokud může být nutné doplnit hodnotu nebo později obohatit, použijte prvky.
  • Pokud je hodnota jasně atomová (boolean, číslo, datum, identifikátor, jednoduchý štítek) a může se vyskytnout nejvýše jednou, pak použijte atribut.

Další způsob, jak to říct, může být:

  • Pokud je to příběh, není objektově orientovaný.
  • Je-li to objektově orientované, modelovat objekty jako prvky a atomové atributy jako atributy.

EDIT: Zdá se, že někteří lidé chtějí zcela vzdát se atributů. Neexistuje nic špatně s tím, ale nelíbí se mi to, jak to blotuje dokumenty a dělá je zbytečně těžké číst a psát ručně.

3
ddaa

Byl jsem jmenován, abych napsal spoustu schémat XML pro integraci svých firemních systémů s našimi klienty. Před deseti lety jsem navrhl tucet z nich a zjistil jsem, že mnoho funkcí rozšíření v praxi nefunguje dobře. Než jsem navrhl nové, hledal (a) jsem ty nejlepší postupy (a přijel sem!). 

Některé z výše uvedených tipů jsou užitečné, ale téměř všechny odkazy jsem neměl rád. Nejlepší místo s designovými doporučeními, které jsem našel, bylo od společnosti Microsoft. 

Nejlepším odkazem je Vzory návrhu schématu XML: Zamezení složitosti . Zde naleznete tyto rady:

zdá se, že mnoho autorů schémat by nejlépe sloužilo pochopení a využití účinné podmnožiny vlastností , které poskytuje schéma W3C XML namísto snahy o pochopení všech esoterických a minutiae jazyka.

podrobná vysvětlení následujících pokynů:

  • Proč byste měli použít deklarace globálních a lokálních prvků
  • Proč byste měli použít deklarace globálních a lokálních atributů
  • Proč byste měli pochopit, jak XML jmenné prostory ovlivňují schéma W3C XML
  • Proč byste měli vždy nastavit elementFormDefault na "kvalifikované"
  • Proč byste měli používat skupiny atributů
  • Proč byste měli používat modelové skupiny
  • Proč byste měli používat vestavěné jednoduché typy
  • Proč byste měli používat složité typy
  • Proč byste neměli používat notační deklarace
  • Proč byste měli pečlivě používat substituční skupiny
  • Proč byste měli upřednostňovat klíč/keyref/jedinečné přes ID/IDREF pro omezení identity
  • Proč byste měli používat chameleonová schémata pečlivě
  • Proč byste neměli používat výchozí nebo pevné hodnoty, zejména pro typy xs: QName
  • Proč byste měli používat omezení a rozšíření jednoduchých typů
  • Proč byste měli používat rozšíření komplexních typů
  • Proč byste měli pečlivě používat omezení složitých typů
  • Proč byste měli pečlivě používat abstraktní typy
  • Používejte zástupné znaky, které poskytují dobře definované body rozšiřitelnosti
  • Nepoužívejte předefinování skupiny nebo typu

Moje rada o jejich radách je, že když říkají "opatrně" , měli byste se tomu prostě vyhnout. Můj dojem je, že specifikace schématu nebyla napsána vývojáři softwaru. Pokoušeli se použít některé koncepty objektové orientace, ale udělali to nepořádek. Mnoho mechanismů rozšíření je zbytečných nebo extrémně podrobných. Nechápu, jak by někdo mohl vymyslet omezení složitých typů.

Další dva pěkné články na této stránce jsou:

A jeden tip, který je všudypřítomný, je specifikovat vaše schémata s něčím jiným než oficiální specifikace. Relax NG vypadá nejoblíbenějším jazykem specifikace. Naneštěstí ztratíte jednu z nejlepších vlastností, která je standardizací. 

1
neves

Když navrhujete formát založený na XML, je často dobré přemýšlet o tom, co reprezentujete. Zkuste posmívat některá data XML, která vyhovují účelu, který chcete. Jakmile budete mít něco, s čím jste spokojeni a které splňují vaše požadavky, vytvořte schéma pro jeho ověření.

Když navrhuji formát, mám tendenci používat prvky pro uchovávání datového obsahu a atributy pro použití charakteristik pro data, jako je id, jméno, typ nebo jiné metadata o datech, které prvek obsahuje.

V tomto ohledu může být reprezentace XML pro souřadnice:

<coordinate type="cartesian">
  <ordinate name="x">0</ordinate>
  <ordinate name="y">1</ordinate>
</coordinate>

To se týká různých souřadnicových systémů. Pokud jste věděli, že budou vždy karteziánští, lepší implementace by mohla být:

<coordinate>
  <x>0</x>
  <y>1</y>
</coordinate>

Ten by samozřejmě mohl vést k podrobnějšímu schématu, protože každý typ elementu by potřeboval deklarovat (i když doufám, že byl definován složitý typ, který by pro tyto prvky skutečně dělal tvrdou práci).

Stejně jako v programování, často existuje několik způsobů, jak dosáhnout stejných cílů, ale v mnoha situacích není správné a špatné, prostě lepší a horší. Důležité je zůstat konzistentní a snažit se být intuitivní, aby když se ostatní podívali na vaše schéma, mohli pochopit, čeho jste se snažili dosáhnout.

Měli byste vždy zobrazit schémata a zajistit, aby XML napsané proti schématu označilo jako takové. Pokud nemáte řádně verzi XML, pak přidávání dodatků do schématu a podpora XML zapsaného do staršího schématu bude mnohem obtížnější.

1
Jeff Yates

V našich Java-projektech často používáme JAXB , abychom automaticky analyzovali XML a transformovali jej do objektové struktury. Myslím, že pro jiné jazyky budete mít něco podobného. Vhodným generátorem lze automaticky vytvořit strukturu objektu ve vámi zvoleném programovacím jazyce. Díky tomu je zpracování XML často mnohem snazší a zároveň má přenosnou XML reprezentaci pro komunikaci mezi systémy.

Pokud používáte takové automatické mapování, zjistíte, že to omezuje schéma - <coordinate> <x> 0 </x> <y> 1 </y> </coordinate> je způsob, jak jít, pokud nechcete dělat speciální magii v překladu. Skončíte s třídou Coordinate se dvěma atributy x a y s příslušným typem deklarovaným ve schématu.

1
Hans-Peter Störr

Podívejte se na vztahy mezi údaji, které se snažíte reprezentovat, je nejlepším přístupem, který jsem našel.

0
Rob Wells

Často se ocitám v boji se stejným problémem, ale zjistím, že v praxi to nevadí, xml jsou jen data.

To znamená, že obvykle dávám přednost "pokud něco říká o uzlu je to atribut, jinak je to childnode" přístup.

Ve svém příkladu bych použil:

<coordinate>
    <x>0</x>
    <y>1</y>
</coordinate>

protože x a y jsou vlastnosti souřadnic, které ve skutečnosti neříkají nic o XML, ale o objektu, který reprezentuje.

0
Kris

Našel jsem formu atributu lépe zvládnutelnou při práci s kartézskými souřadnicemi. Moje projekty mají tendenci vyžadovat více jmenných prostorů a sdílení definice typu souřadnic mezi jmennými prostory je ve formuláři dílčích prvků ošklivé. Ve formuláři dílčího elementu musíte buď kvalifikovat dílčí elementy, jmenné prostory pro žonglování v základním nebo kořenovém elementu, nebo použít výchozí názvy nekvalifikovaných prvků (tj. jmenný prostor schovávající se )

0
Caleb

Myslím, že záleží na tom, jak složitá nebo jednoduchá je struktura.
Udělám x a y jako atribut, pokud x a y nemají své vlastní detaily

Můžete se podívat na HTML nebo jakoukoliv jinou formu značení, která se používá k definování věcí (XAML v případě WPF, MXML v případě flash), aby pochopila, proč je něco vybráno jako atribut jako proti dětskému uzlu)

pokud x a y nebudou opakovány, mohou to být atributy.

Řekněme, že souřadnice mají více x a y, myslím, že xml doesnt povolit více atributů se stejným názvem pro uzel. V takovém případě budete muset použít podřízené uzly.

0
shahkalpesh

Neexistuje nic, co je v zásadě špatné, s použitím elementu nebo sub-elementu pro každou hodnotu, kterou chcete reprezentovat.

Hlavní úvahou je, že někdy je čistší použít atribut. Jelikož prvek může mít pouze jeden atribut daného jména, uvízl jste s mohutností 1: 1. Pokud reprezentujete data jako podřízený prvek, můžete použít jakoukoliv kardinálnost, kterou byste chtěli (nebo ji můžete později rozšířit).

Reakce Roba Wellse nahoře je správná: záleží na vztazích, které se snažíte modelovat.

Kdykoliv se zdá, že nikdy nebude nic jiného než vztah 1: 1, atribut může být čistší.

0
BQ.

Zde je skvělý seznam metod pro navrhování XML gramatiky. 

Jak bylo uvedeno výše, jedná se o subjektivní praxi, ale tato stránka poskytuje některé užitečné pokyny, jako je „použití tohoto vzoru k řešení problému X“… nebo „výhody a nevýhody…“.

0
Zearin