[Discussie] Stelling: XML attributen zuigen!

[mbravenboer]

Ik dacht: kom laat ik ook eens een discussie starten .
(sorry D2k dat het weer een discussie is die 's nachts begint )

De stelling: XML attributen zuigen!

Nu denk je natuurlijk: "huh? Martin vindt iets aan XML zuigen ". Ja inderdaad, dat vind ik .

Waarom vind ik dat XML attributen zuigen?

Wat zijn attributen?

Om mijn stelling uit te leggen moeten we eerst bekijken wat attributen eigenlijk zijn. Attributen zijn naar mijn mening bedoelt als aantekeningen bij elementen. Waarom noem ik het aantekeningen? XML attributen maken namelijk geen onderdeel uit van de structuur van een XML document. Als je met behulp van XPath een pad aangeeft in een XML document hoef je namelijk geen rekening te houden attributen die zich op dit pad kunnen bevinden.

Je kunt het als volgt zien: het model van XML is een boom. Deze boom kan je plat tekenen op een blaadje. Attributen zou je mooi kunnen zien als elementen die niet op het blaadje getekend worden, maar bij een knoop omhoog steken.

Als je XML attributen als aantekeningen gaat zien, wordt het een stuk eenvoudiger om beslissingen te gaan nemen over wat je een attribuut maakt en wat niet. Dit is namelijk een zeer vaak voorkomende en lastige beslissing, waarover de meningen nogal over verschillen. Iets wat geen onderdeel zou moeten zijn van een data-structuur, maar een aantekening is bij een onderdeel van de structuur is een attribuut.

Laat ik als voorbeeld het href attribuut van een link nemen: Je creeert in HTML een verwijzing naar een ander (HTML) document door een stukje HTML content in een 'a' element op te nemen. De content van het 'a' element is dus een link. De url zelf is geen link: dit is een vrij essentiele aantekening bij deze structuur. Als url in de content van het element zou staan, zou de url zelf ook een link zijn, wat natuurlijk niet klopt. Daarom is href dus een attribuut geworden.

Allemaal heel leuk, maar ik zie geen probleem!

Ik zei een stukje geleden dit: Als je XML attributen als aantekeningen gaat zien, wordt het een stuk eenvoudiger om beslissingen te gaan nemen over wat je een attribuut maakt en wat niet. Eigenlijk zei ik dat verkeerd. Er had namelijk moeten staan: Als je XML attributen als aantekeningen gaat zien, zou het een stuk eenvoudiger moeten worden om beslissingen te gaan nemen over wat je een attribuut maakt en wat niet.

Ok, het zal je duidelijk zijn dat er volgens mij dus een probleem is . Ik hoop dat ik je ondertussen nieuwsgierig gemaakt heb .

Er zijn twee problemen met attributen:

1. De syntax van attributen is compacter dan de syntax van elementen. Hierdoor ben je geneigd om onterecht uit gemakszucht sub-structuur te verbannen naar de status van aantekening: attribuut. Je keuze of iets een attribuut of subelement moet zijn, wordt dus beinvloed door het 'gemak' van attributen. Dit gemak speelt vooral een rol als je XML zelf wilt gaan inlezen in een bepaalde taal: attributen werken dan vaak makkelijker.

2. Attributen bieden minder mogelijkheden dan elementen. Attributen bieden niet de mogelijkheid tot sub-structuur. Hierdoor ben je gedwongen om elementen te gaan gebruiken als je complexere aantekeningen wilt maken met sub-structuur. Hier moet je dus aan de hand van de complexiteit van je aantekening gaan kiezen voor de een of de ander, wat een duidelijke scheiding tussen structuur en aantekeningen sterk in de weg staat.

Wat zijn de gevolgen van deze gebreken?

1. Je ziet op veel plaatsen het gebruik aan sub-structuur in attributen opgelost door maar zelf een sub-structuur te gaan verzinnen. Dit komt dan vaak neer op een token serie, gescheiden door spaties. Het lijkt mij duidelijk dat dit de principe van XML ernstig beschadigd.

2. Puristen die het vertikken om sub-structuur in attributen te gaan ontwikkelen zijn genoodzaakt om gegevens die duidelijk aantekeningen zijn, te gaan gebruiken als echte structuur. Dit leidt tot grote verwarring en verwarrende XML documenten.

Ik ben benieuwd wat jullie hiervan vinden .

1. Zijn jullie het met me eens?
2. Heb je weleens ergens anders vergelijkbaar commentaar gelezen?
3. Wil je me op andere gedachten brengen? (veel succes in dat geval ).

<bron-vermelding>
Ik ben gedeeltelijk op deze gedachten gekomen na het werken met ATermen: een alternatief voor XML. ATermen laten zoals je vast zult begrijpen wel aantekeningen met sub-structuur toe
</bron-vermelding>

Laat de strijd beginnen!

[ACM]

Mja, ik vind wel dat je gelijk hebt

Ik vond het ook al zo vreemd dat je eigenlijk voor veel dingen "zomaar" attributen zou maken, terwijl het ook subelementen mogen zijn etc.

[mbravenboer]

ACM: Mja, ik vind wel dat je gelijk hebt

Dat schiet ook niet op . Als iedereen het met me eens is, wordt dit natuurlijk niks .

[Verwijderd]

Wanneer je attributen gebruikt voor waar ze goed in zijn, zie ik geen probleem.
Attributen in combinatie met een schema of DTD zijn uitstekend te gebruiken om bv. (database) recordsets zo compact mogelijk weer te geven, en da's wel zo prettig bij het transport over 't Internet bijvoorbeeld. Flinke recordsets zijn met gebruik van attributes gauw 40 tot 50% kleiner dan "traditionele" XML files.

Voor dingen als sub-structuren zijn ze natuurlijk absoluut ongeschikt, en daar moet je ze dan ook gewoon niet voor gebruiken.

Gewoon toepassen wanneer 't nuttig is, en z'n voor- en nadelen zien.

[.oisyn]

ik ben niet zo into xml, maar toen ik voor het eerst een xml document zag dacht ik al gelijk van: heej, waarom zijn er attributen en is er substructuur (ik dacht niet in die woorden, maar daar komt het op neer )

dat er substructuur moet zijn is logisch, anders valt bijna de hele functionaliteit van xml weg.

dus waarom die attributen? dat url voorbeeldje wat je gaf... dat zou naar mijn idee ook moeten zijn

code:

<a>
    <link>De link</link>
    <href>http://de_url</href>
</a>

maw, ik ben het eens met de stelling, en ik voeg er aan toe: dump de attributen in de trashcan, dan ben je ook van al het gezeik af

[mbravenboer]

Afterlife: zo compact mogelijk weer te geven

Dit komt behoorlijk overeen met mijn opmerking over 1 van de nadelen van attributen: de compacte syntax ten opzichte elementen nodigt snel uit tot misbruik van attributen...

en da's wel zo prettig bij het transport over 't Internet bijvoorbeeld. Flinke recordsets zijn met gebruik van attributes gauw 40 tot 50% kleiner dan "traditionele" XML files.

Maar ja, om nu een groot nadeel van XML: de verbositeit, op te gaan lossen met het misbruik van attributen vind ik wat ver gaan. Ik vind het verkeerd om attributen te misbruiken om dit probleem op te lossen: dit probleem staat verder op zich zelf..

[mbravenboer]

OiSyN: dus waarom die attributen? dat url voorbeeldje wat je gaf... dat zou naar mijn idee ook moeten zijn...

Inderdaad is een goed voorbeeld. Toen ik het voorbeeld zat te tikken dacht ik aan dezelfde oplossing. Het is goed dat je een apart element voor de 'content' van de link hebt gebruikt.

dump de attributen in de trashcan, dan ben je ook van al het gezeik af

Op zich geen verkeerde gedachte, maar attributen hebben toch een voordeel: ze zijn geen onderdeel van de structuur. Bij XML is het niet zo duidelijk, maar je kunt een element zien als een data-type. Attributen kunnen erg makkelijk zijn omdat je aantekeningen aan een element kunt hangen zonder dat het data-type daardoor wordt aangepast.

Je kunt het data-type dus zonder kennis van de aanwezige attributen gebruiken. Deze 'aantekeningen' zijn daarom denk ik wel degelijk erg handig.

Daarom zou ik ook liever een andere oplossing zien: attributen met sub-structuur . Hoe de concrete syntax er dan uit gaat zien is een probleem wat later dan wel op te lossen is...

[Verwijderd]

Op zaterdag 22 december 2001 00:28 schreef mbravenboer het volgende:
Maar ja, om nu een groot nadeel van XML: de verbositeit, op te gaan lossen met het misbruik van attributen vind ik wat ver gaan. Ik vind het verkeerd om attributen te misbruiken om dit probleem op te lossen: dit probleem staat verder op zich zelf..

Je zult 't op de een of andere manier moeten oplossen, en attributen werken in zo'n geval bij platte structuren vrij aardig.
Alternatief is ongeveer wat je bij veel javascript driven websites ziet: variabelen (lees: element- of attributnamen) beperken tot 2 karakters, en alle leesbaarheid laten varen.

OK, attributen zijn een lelijke toevoeging aan XML, maar ze hebben wel hun nut.
Het feit alleen al dat ze hun nut hebben betekent misschien wel dat XML zelf zuigt.

[mbravenboer]

Afterlife: Alternatief is ongeveer ...

of een alternatief, wellicht binary, opslag-formaat maar dat is een hele andere discussie .

Het feit alleen al dat ze hun nut hebben betekent misschien wel dat XML zelf zuigt.

Hum, zo zou je het ook kunnen zien ja . hehe .

[.oisyn]

mbravenboer: Daarom zou ik ook liever een andere oplossing zien: attributen met sub-structuur . Hoe de concrete syntax er dan uit gaat zien is een probleem wat later dan wel op te lossen is...

waarom stop je ze dan niet in een extra element waar je een vaste naam voor reserveert...

bijvoorbeeld:

code:

<label>
    <text>blaat</text>
    <location>
      <x>10</x>
      <y>16</y>
    </location>
    <attributes>
      // hier gooi je vervolgens je aantekeningen in
    </attributes>
</label>

nadeel hiervan is wel dat je dan de element-naam "attributes" niet meer mag gebruiken... is wel wat op te verzinnen, maar daar gaat het verder even niet om.

[mbravenboer]

OiSyN: waarom stop je ze dan niet in een extra element waar je een vaste naam voor reserveert...

Dat is inderdaad een prima oplossing (maar uiteraard is het een work-around) die ik in feite ook heel af en toe gebruik . De syntax wordt er natuurlijk niet echt compacter op, maar ja, dat was hij toch al niet .

Maar goed, het gaat niet alleen om mij, maar om het verbeteren van een standaard (jaja, jeugdig enthousiasme ). Alleen op die manier kan je namelijk in andere standaard tools zoals XSLT, DOM en SAX parsers enz. ook makkelijk gebruik maken van gestructureerde-attributen, maar goed zelfs dat is eigenlijk nog geeneens echt een groot probleem.

nadeel hiervan is wel dat je dan de element-naam "attributes" niet meer mag gebruiken... is wel wat op te verzinnen, maar daar gaat het verder even niet om.

Daar zou je inderdaad gewoon ff een andere namespace voor kunnen maken .

Bedankt voor deze leuke toevoeging .

[mbravenboer]

tomato wees mij nog even op deze draad:

http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Aug-1999/0274.html

In het begin begon ik enthousiast te lezen, maar later betrok mijn gezicht... Dit gaat precies de verkeerde kant op naar mijn mening. Attributen worden hier gedegradeerd tot afgekorte elementen en dat zijn ze naar mijn mening dus absoluut niet. Attributen zijn fundamenteel andere noties dan elementen.

Een alternatief voor de syntax van OiSyn: voer een aparte namespace in voor attributen. Laten we deze even om de syntax kort te houden "a" dopen.

Je krijgt dan:

code:

<label>
    <a:blaat>
     //content van het attribuut
    </a:blaat>

    <a:blaat2>
     //content van het attribuut
    </a:blaat2>

    <text>blaat</text>
    <location>
      <x>10</x>
      <y>16</y>
    </location>
</label>

Voor 'a' zou het dan worden (hum dat is ietwat verwarrend met de namespace afkorting):

code:

<a>
  <a:href>http://blaat</a:href>
  Dit is een link!
</a>

Probleem hierbij: de attribuut nodes vallen nu in een andere namespace dan die van het document. Das vreemd en dat maakt deze opossing dan ook absoluut niet fraai. Gelijk maakt het ook attibuten in een andere namespace onmogelijk...

Voordeel: compacte syntax en duidelijk onderscheid tussen attributen en elememten. Met de afkorting 'a' kan de naam attribuut bovendien gelijk wel veranderd worden in annotation .

[Orphix]

Nou nou zuigen, wat een geflame toch weer

Ja ik heb het me ook weleens afgevraagd. Waarom bv een id van een item als attribuut wordt meegegeven ipv element.

Maar dat idee over sub-attributen, wat is daar dan het grote voordeel van in vergelijking met gewone elementen (en hun kinderen) ? Oftewel, waarom eigenlijk een soort 2e vrijwel gelijke structuur inbouwen in plaats van de attributen weggooien?

[mbravenboer]

Laten we even net doen of we de baas zijn in het W3C en heel de syntax van XML omver mogen gooien . Je zou het volgende kunnen doen.

code:

<label>
    <@blaat>
     //content van het attribuut
    </@blaat>

    <@blaat2>
     //content van het attribuut
    </@blaat2>

    <text>blaat</text>
    <location>
      <x>10</x>
      <y>16</y>
    </location>
</label>

Attributen hebben nu dus een aparte syntax: <@ ... >.

Voordelen:
- compact
- namespace weer mogelijk op attribuut
- zeer logisch: in XPath worden attributen ook aangeduid met @ .

Eigenlijk vind ik hem best wel yummie . Gesteld dat dit ooit erkend zou worden als een gebrek, zou het daarom best wel een goede oplossing zijn denk ik. Bovendien zou je ook nog de 'oude' compacte syntax kunnen toestaan voor attributen die geen structuur nodig hebben.

Voor 'a' zou het dan worden:

code:

<a>
  <@href>http://blaat</@href>
  Dit is een link!
</a>

[mbravenboer]

Orphix: Nou nou zuigen, wat een geflame toch weer

Je moet toch wat doen om mensen tegenwoordig nog te shockeren .

Maar dat idee over sub-attributen, wat is daar dan het grote voordeel van in vergelijking met gewone elementen (en hun kinderen) ? Oftewel, waarom eigenlijk een soort 2e vrijwel gelijke structuur inbouwen in plaats van de attributen weggooien?

Vanwege het aantekeningen idee: attributen zijn in feite aantekeningen van een element die geen onderdeel uitmaken van de structuur van het document. Als je tools schrijft die op een bepaalde structuur werken kunnen ze attributen daardoor negeren als ze dat willen. Zodra attributen deel uit gaan maken het data-type krijg je problemen: dan kan je ze niet meer negeren.

[Nikel]

Ik heb helemaal geen verstand van xml, maar ik had ooit eens de volgende url http://www.w3schools.com/xml/xml_attributes.asp doorgelezen en moest daar nu meteen aan denken. Daar staat dat je attributen gebruikt voor metadata en elementen voor de data zelf. Deze aanpak lijkt mij volkomen logisch en ik zie dan ook geen probleem. Wat zie ik nu precies over het hoofd?

[tomato]

Nikel: Wat zie ik nu precies over het hoofd?

Mogelijke sub-structuren van je meta-date zoals je dit gemakkelijk in elementen uit zou kunnen drukken, maar moeilijk of niet binnen een attribute.

[Orphix]

Op zaterdag 22 december 2001 01:27 schreef mbravenboer het volgende:
Zodra attributen deel uit gaan maken het data-type krijg je problemen: dan kan je ze niet meer negeren.

De 'programmeur' beslist toch welke elementen gebruikt gaan worden? Dit is dus puur een efficientie winst voor de parser?

[Nikel]

Op zaterdag 22 december 2001 01:31 schreef tomato het volgende:
Nikel: Wat zie ik nu precies over het hoofd?

Mogelijke sub-structuren van je meta-date zoals je dit gemakkelijk in elementen uit zou kunnen drukken, maar moeilijk of niet binnen een attribute.

Ja, als ik nu nadenk (maar ik ben niet helemaal helder meer) lijkt het me logisch dat je je metadata ook in een bepaalde structuur kunt vastleggen, net als de data zelf. Maar wat is de reden waarom dit niet zo is bedacht in xml? Dat het zo makkelijker is een parser te maken? Of andere redenen?

[.oisyn]

Op zaterdag 22 december 2001 01:24 kwam mbravenboer met een alternatief voor namespaces

Heh dat was nou precies wat ik in mijn hoofd had... een van de tekens die bovenaan de nummertoetsen zitten ervoor

[mbravenboer]

Ik merk dat niet iedereen echt inziet waarom ik attributen 'evil' vindt en waarom attributen toch nodig zijn.

Ik heb er daarom even een uitstekend voorbeeld bij gepakt wat ik laatst tegen kwam in een bekende tutorial.

Als je bij een XML wilt aangeven dat het een instantie van meerdere XML Schemas is moet je dat ongeveer zo doen:

code:

<BookStore xmlns="http://wwwBookRetailers.org"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www. BookRetailers.org
                      BookSeller.xsd
                      http://www. repository.org
                      SchemaRespository.xsd">

Hier zie je dus duidelijk dat er aangeklooid is. Waarom moest dit? De declaraties van de namespaces en de schema-locaties mogen geen onderdeel van het data-type BookStore. Daarom zijn het attributen: aantekeningen bij het BookStore element.

Hoe zouden gestructureerde attributen dit oplossen?

code:

<BookStore>
    <@xmlns-dec>
      <abbr>xsi</abbr>
      <uri>http://www.w3.org/2001/XMLSchema-instance</uri>
    </@xmlns-dec>

    <@xmlns-dec>
      <@xsi:schemaLocation>http://www. bookretailers.org/schema.xsd</@xsi:schemaLocation>

      <uri>http://www.BookRetailers.org</uri>
    </@xmlns-dec>

    <@xmlns-dec>
      <@xsi:schemaLocation>http://www.repository.org/schema.xsd</@xsi:schemaLocation>

      <abbr>repos</abbr>
      <uri>http://www. repository.org</uri>
    </@xmlns-dec>

Het is de eerste keer schrikken omdat je de syntax niet kent, maar als je daar even doorheen weet te prikken is het een hele logische en fraaie oplossing. Als je liever niet wilt dat attributen vaker kunnen voorkomen verzamel je de namespace declaratie gewoon in 1 gestructureerd attribuut .

[mbravenboer]

Nikel: Ja, als ik nu nadenk (maar ik ben niet helemaal helder meer) lijkt het me logisch dat je je metadata ook in een bepaalde structuur kunt vastleggen, net als de data zelf.

Dat is inderdaad ook een hele goede omschrijving van het probleem...

Maar wat is de reden waarom dit niet zo is bedacht in xml? Dat het zo makkelijker is een parser te maken? Of andere redenen?

Ik vermoed dat dit gedaan is om compatible te blijven met SGML en de zaak op HTML te laten lijken. Ik heb bepaald niet de illusie dat ik denk dat niemand ooit hieraan gedacht heeft. Waarschijnlijk is de huidige oplossing een (naar mijn mening verkeerd) compromis gemeest om XML toegankelijker te maken.

[Verwijderd]

Op zaterdag 22 december 2001 01:34 schreef Nikel het volgende:
Ja, als ik nu nadenk (maar ik ben niet helemaal helder meer) lijkt het me logisch dat je je metadata ook in een bepaalde structuur kunt vastleggen, net als de data zelf.

Jep, via een DTD of een schema.

[Nikel]

Op zaterdag 22 december 2001 01:55 schreef mbravenboer het volgende:
Waarschijnlijk is de huidige oplossing een (naar mijn mening verkeerd) compromis gemeest om XML toegankelijker te maken.

Zou goed kunnen, maar dat weten ze dan natuurlijk heel goed, en dat zouden ze bij het w3 consortium dan dus vanzelf oplossen in xml 2.0, of denk ik nu weer veel te makkelijk?

[mbravenboer]

Nikel: Zou goed kunnen, maar dat weten ze dan natuurlijk heel goed, en dat zouden ze bij het w3 consortium dan dus vanzelf oplossen in xml 2.0, of denk ik nu weer veel te makkelijk?

Ja . Als XML zo radikaal zou worden aangepast zou dat een ramp betekenen: XML is al zo ontzettend veel in gebruik, dat het veel te veel bestaande tools onwerkbaar zou maken. Ik denk dat eventuele aanpassingen van XML veel minder radicaal zullen zijn.

[Orphix]

Hier zie je dus duidelijk dat er aangeklooid is. Waarom moest dit? De declaraties van de namespaces en de schema-locaties mogen geen onderdeel van het data-type BookStore. Daarom zijn het attributen: aantekeningen bij het BookStore element.

Tja ik weet niet, misschien dat we een beetje zijn vastgelopen op dat idee. Als je bereidt bent af te doen van het meta-data idee en gewoon zegt 'tja, <xmlns-dec> heeft iets met bookstore te maken, namelijk hoe het moet worden geinterpreteerd, dus kan het als element worden gebruikt'
Ik begrijp dat het niet helemaal 'netjes' is maar ik denk dat de state-of-mind veranderen niet eens zo verkeerd is, en misschien wel makkelijker dan de XML ev. onnodig moeilijker maken.

Maar nogmaals, ik begrijp je wel, het is absoluut 'netter' om de daadwerkelijke data te scheiden van waardes die aangeven hoe je die data moet interpreteren.

Maar is zoiets als dit dan ook raar?

code:

<document>
   <type>HTML</type>
   <modified>12-21-2001</modified>
</document>

Dit komt ongeveer op hetzelfde neer, maar klinkt wel een stuk logischer. Die uri's die jij noemt zijn meer gericht op de XML data zelf, misschien dat daar gewoon een aparte regel voor kan worden gebruikt. Net als bij HTML de W3C DTD als 1e regel oid.

Hmm ik besef me nu dat attributen natuurlijk wel altijd voor de elementen moeten worden gelezen. Dat zou dan ook in jouw systeem moeten komen denk ik

Al met al best aardig om over na te denken

[Nikel]

Ze zouden in de hele computerbranche eens op moeten houden met backwards compatible te zijn, dat zou een heleboel meer problemen oplossen .

Nu denk ik even aan vuige oplossingen als javascript opnemen als commentaar in html zodat oudere browsers het ook trekken, bah.

Volgens mij heeft jouw xml attribuut oplossing met die @-jes ervoor daar ook iets van weg, of niet?

[mbravenboer]

Orphix: namelijk hoe het moet worden geinterpreteerd, dus kan het als element worden gebruikt'

Hum, tja.. ik kan helaas geen beter tegenvoorbeeld verzinnen van de nadelen hiervan dan schema-declaratie van hierboven.... Ik denk dat je de kern van mijn verhaal wel inziet zoals je verderop ook zegt. Als attributen als content gaat opnemen wordt het ook echt onderdeel van de structuur. Dat is niet alleen lelijk, maar het kan ook problemen veroorzaken: aanwezigheid van onbekende sub-elementen (ook al zitten ze in een andere namespace) verandert het type van een knoop. Nu is het helaas zo dat dit eigenlijk bij attributen op dit moment ook het geval is, maar dat is naar mijn mening dus ook fout .

Maar is zoiets als dit dan ook raar?

code:

<document>
   <type>HTML</type>
   <modified>12-21-2001</modified>
</document>

Tja, dat ligt eraan wat je hier beschrijft. In principe is hier niets mis mee als je meta-eigenschappen van een document beschrijft. Als je content van het document er ook in staat is het wel lelijk: het type is geen onderdeel van het document.

Merk op dat als je content afscheidt in een aparte tag je in feite hetzelfde effect krijgt als de work-around van OiSyN:

code:

<document>
   <type>HTML</type>
   <modified>12-21-2001</modified>
   <content>
       ....
   </content>
</document>

Nu stop je dus niet de attributen in een afgescheiden deel, maar de content... Op zich ook een aardige work-around.

Net als bij HTML de W3C DTD als 1e regel oid.

Das een processing instruction, nog zo'n vreselijk ding .

Hmm ik besef me nu dat attributen natuurlijk wel altijd voor de elementen moeten worden gelezen. Dat zou dan ook in jouw systeem moeten komen denk ik

Zeker, das ook best wel een complicatie .

Al met al best aardig om over na te denken

Idd, het is natuurlijk wel erg hoog gegrepen om te denken dat dit ook daadwerkelijk doorgevoerd gaat worden, maar het is wel leuk om na te denken over wat data nu eigenlijk is, wat attributen zijn en wat structuur is. Wellicht gaat een van jullie ooit nog meewerken aan de opvolger van XML en denkt hij aan dit verhaal .

[mbravenboer]

Nikel: Ze zouden in de hele computerbranche eens op moeten houden met backwards compatible te zijn, dat zou een heleboel meer problemen oplossen .

Hehe . en het zou nog veel meer problemen veroorzaken .

Nu denk ik even aan vuige oplossingen als javascript opnemen als commentaar in html zodat oudere browsers het ook trekken, bah.

Idd, das ook een voorbeeld. Tegenwoordig zou dat volgens de XHTML specificaties in een CDATA block moeten, daar is weer niets mis mee .

Waar wel iets mee is: in XHTML is een CDATA sectie commentaar . De debiel die dat verzonnen heeft moeten ze per direct verbannen naar de kleinste ijs-schots in de Noordelijke IJszee. In XML moet een CDATA sectie gewoon niet geparsed worden gebruikt. Dit is een prachtig systeem om ranzige content op te kunnen nemen die niet aan XML voldoet. In XHTML is het om onbegrijpelijke redenen opeens commentaar. Volslagen idioot als je het vergelijkt met de regels die voor XML gelden. Je merkt het: hier kan ik boos om worden .

[Verwijderd]

Ik zie eigenlijk niet in waarom er zo nodig een scheiding moet zijn tussen 'aantekening'-data en normale data.

Ik bedoel, dat onderscheid hebben we in normale databases als MySQL enzo toch ook nooit nodig gehad ?

(Ik gebruik geen attributen in mijn XML data.)

PS. Comments in XML is ook zoiets.. maar das weer een heel ander verhaal.

[Verwijderd]

Als ik het goed begrijp gaat het op het scheiden van content en meta-informatie. Elementen gebruiken is geen oplossing omdat dit door de gebruiker zelf geimplementeerd moet worden en niet consistent zal worden. Om diezelfde reden is het gebruik van namespaces niet geschikt. We zoeken dus een manier om elementen op een standaard manier te scheiden in content en meta-info elementen.

Ikzelf vind de oplossing met een @ ervoor een mooie oplossing. Parse-technische levert dit ook geen problemen op aangezien @ niet in de productie van een NCName mag voorkomen. Alleen deze is niet backwards compatible.

Een andere oplossing is om nog een niveau toe te voegen als een namespace, maar dan is in de standaard vastgelegd welke mogelijk zijn: attributen (at), namespaces (ns) en content (cn). Als er geen is gedefinieerd, dan is het content.
De : kan niet als separator dienen omdat : maar een keer voor kan kopen in een QName, als scheider van Prefix en Local. Alternatieven zijn . - _ Ik heb in het voorbeeld voor _ gekozen.

code:

<link>
  <at_xml:lang>US-en</at_xml:lang>

  <ns_nsdecl>
    <abbr>xsi</abbr>
    <uri>http://www.w3.org/2001/XMLSchema-instance</uri>
  </ns_nsdecl>

  <target>_new</target>
  <link>http://tweakers.net</link>
  <text>Tweakers homepage</link>
</link>

PS. Ik heb ook nog een suggestie: Verplicht XML parsers niet tot DTD's te moeten parsen en dan niet hoeven te valideren. Of parsen EN valideren of gewoon niet parsen en niet valideren.

[Orphix]

PS. Ik heb ook nog een suggestie: Verplicht XML parsers niet tot DTD's te moeten parsen en dan niet hoeven te valideren. Of parsen EN valideren of gewoon niet parsen en niet valideren.

Dat kan nu toch al? Ik heb (tot m'n schaamte ) eigenlijk nog nooit serieus een DTD gebruikt. Well-formed is voor mij goed genoeg. Ik hoop iig dat je met 'niet valideren' niet bedoelt op het 'probeer zoveel mogelijk te parsen, ook al zijn er soms geen close tags of zijn ze niet mooi genest'

[Verwijderd]

Ik bedoel als je zelf een XML parser library schrijft. Ik kan me heel goed voorstellen dat dat lastig kan zijn als je een embeded XML parser hebt voor een of ander mobiel device of een magnetron ofzo.

Om niet van de attributen af te dwalen: Het is ook irritant dat er geen dubbele attributen mogen voorkomen, zowel gewoon als met geresolvde namespaces:

code:

<a xmlns:n1="AAP"
   xmlns:n2="BEER"
   xmlns:n3="BEER"
   xmlns:n4="KOE"
  <b a="1" a="2" />  <!-- FOUT -->
  <b a="1" n1:a="2" />    <!-- TOEGESTAAN -->
  <b n1:a="1" n1:a="2" /> <!-- FOUT -->
  <b n2:a="1" n3:a="2" /> <!-- FOUT -->
  <b n1:a="1" n2:a="2" /> <!-- TOEGESTAAN -->
</a>

<a xmlns="KOE"
   xmlns:n1="KOE">
  <b a="1" a="2" />  <!-- FOUT -->
  <b a="1" n1:a="2" />     <!-- FOUT -->
</a>

[Rense Klinkenberg]

mmm, ik las de topictitel en dacht: lekker een controversiële discusse. Maar heleeas is iedereen het erg met elkaar eens.

Persoonlijk heb ik totaal geen hekel aan attributen. nu moet ik zeggen dat ik ze ook anders bekijk dan de visie van Martin. Op zich klopt het natuurlijk wel zoals hij het zegt, dat attributen eigenlijk aantekeningen zijn en geen voor de content belangerijke informatie mogen hebben, maar ik zie het toch anders.

Mijn idee van xml ziet de reeds eerder genoemde boom op een iets andere manier. De root van het xml document zou als het ware de stam zijn. Elke zijtak wordt dat gevormd door een element. De zijtakjes van die tak worden ook weer gerepresenteerd als elementen. Daar de zijtakken van ook, enz.

wie de natuur kent, weet ook dat geneen tak er hetzelfde uitziet. Doch heeft elke tak maar 1 dikte en 1 ouderdom. Dit zijn dus allemaal specifieke eigenschappen van die ene tak. Dat zijn dus perfecte attributen.

Mijn boom zou er dus als volgt uitzien:

code:

<stam dikte="10" leeftijd="5">
    <tak dikte="5" leeftijd="3">
      <tak dikte="4" leeftijd="2">
        <tak dikte="1" leeftijd="0" />
      </tak>
    </tak>
</stam>

* Rense Klinkenberg is blij dat het winter is en dus geen bladeren onder alle taken hoeft te hangen

[mbravenboer]

freak007: Dit zijn dus allemaal specifieke eigenschappen van die ene tak. Dat zijn dus perfecte attributen.

Leuk voorbeeld .

Maar volgens bij kan je dit juist perfect zien als aantekeningen bij een tak! Ze maken immers geen essentieel onderdeel uit van de structuur van de tak. Ik zie in jouw voorbeeld eerder opnieuw de noodzaak van gestructureerde attributen. Stel bijvoorbeeld dat je wilt opslaan welke vogels er vaak op die tak zitten. Dit is geen onderdeel van de structuur, maar typische meta-informatie. Nu valt er natuurlijk wat voor te zeggen dat dat in een ander document zou moeten, maar in principe zou het ook perfect als gestructureerd attribuut kunnen...

* mbravenboer is blij dat het winter is en dus geen bladeren onder alle taken hoeft te hangen

Gelukkig heb je geen denneboom genomen , zou wel toepasselijk zijn .

[Verwijderd]

Op zaterdag 22 december 2001 15:34 schreef Orphix het volgende:

Dat kan nu toch al? Ik heb (tot m'n schaamte ) eigenlijk nog nooit serieus een DTD gebruikt. Well-formed is voor mij goed genoeg.[...]

Waarom schaamte? Het gebruik van een DTD of ander groen boekje is toch gewoon een ontwerp-beslissing. DTD zou ik alleen gebruiken om programmeurs tegen zichzelf te beschermen en/of als je 3en niet wilt/kunt vertrouwen...

Op zaterdag 22 december 2001 02:31 schreef mbravenboer VEEEL:

Nu snap ik die attributen. Zelf nog niet veel met XML gedaan. Eerst dacht in de richting van 1. en n-elementen of zo. Ignorance is bliss

Maar: waarom de stricte scheiding van data en meta-data. Regelmatig heb je ook weer te maken met meta-meta-data. Maw: waarom moet uit de xml-syntax blijken dat het meta-data betreft?

[OMX2000]

Waar attributen ook heel goed voor gebruikt kunnen worden is als eigenschappen (of aantekeningen) die gebruikt kunnen worden om een beslissing te nemen als je een query doet op een xml boom. Op deze manier worden je Xpath makkelijker/sneller. Of het correct is om je xml aan te passen om er sneller door heen te kunnen "browsen" weet ik niet. Maar in sommige toepassingen wel handig...

Oh ja, een vraagje weet iemand hier iets van XML-infosets???

[Verwijderd]

attributen hebben geen nut in de zin van de basis van XML, je kunt ze t.a.t. vervangen door subtags in de tag waar de attributen zijn geplaatst.

Waar attributen voor kunnen worden gebruikt is syntactische specificering van de tag (bv type, namespace etc), terwijl subtags semantische specificering van de tag voor hun rekening nemen (bv de tag Vissen met subtags Brasem, Baars en Snoek)

Wat meteen een zwakte naar boven brengt in XML: de debieliteit van de XML syntax als het gaat om '<' en '>' en speciale characters. Als je type specificaties in XML wilt opnemen in attributes, en hele namespace constructies gaat verzinnen, waarom wordt dan iets TRIESTS als het feit dat je GEEN '<' IN EEN STRING mag gebruiken niet meegenomen?

1e les compilerbouw op elke willekeurige opleiding: '"' markeert start stringconstant, de volgende '"' markeert het einde van de stringconstant. Je Lexical Analyzer geeft dan een stringconstant token terug etc. Maar nee... de sukkels van W3C dachten zoals altijd, nl. debiel, dus moet je '<' en '>' omschrijven als de html equivalenten. Krijg je van die leuke expressies in XSL(T) (wat de XML syntaxis gebruikt) waarbij je kleiner dan niet als '<' opschrijft maar als '& lt;' (en dan aan elkaar).

Ergo: het is allemaal leuk en aardig die attributes en je zult er zeker wel wat mee kunnen, maar het schiet zn doel voorbij: de onderliggende basis syntaxis is niet correct, waardoor je wel attributes kunt introduceren maar je altijd met een crappy syntaxis blijft zitten, waardoor men ze zoveel mogelijk probeert te vermijden.

Verder: namespaces in XML, allemaal leuk, maar totaal onleesbaar voor een mens. Converteer eens een ADO recordset naar een XML DOM. het zal allemaal kloppen, maar het kost veel te veel tijd om dat te doorgronden. Het wordt al snel een onleesbare brij. Uiteraard zullen er tools komen waardoor je helemaal never nooit meer XML zult zien, wat uitstekend is want de mens werkt beter met menselijke taal en de computer werkt beter met voor de computer ontwikkelde talen, en dat lost ook meteen het geneuzel of attributes nu wel of niet moeten op: je ziet het resultaat toch niet.

Let wel: iedereen die roept dat je XML met de hand zou moeten schrijven is niet goed wijs: het is een beschrijving van een hierarchische structuur van semi-gerelateerde data, met een syntax die alleen leesbaar is, indien je niet al te veel toeters en bellen gebruikt (wat heel goed werkt hoor). Computers zijn veel beter in het genereren van XML dan mensen. Lost ook meteen het probleem op van of attributes er iets toe doen.

[Zoijar]

ik denk dat het gedaan is omdat het goed "mapped" naar bestaande schematische ontwerp diagrammen, zoals UML en "die andere specifiek voor databases waarvan de naam me even ontschoten is". Dat is tenminste het eerste waar ik aan dacht toen ik het zag.

[Verwijderd]

Op maandag 24 december 2001 11:24 schreef Otis het volgende:
Let wel: iedereen die roept dat je XML met de hand zou moeten schrijven is niet goed wijs: het is een beschrijving van een hierarchische structuur van semi-gerelateerde data, met een syntax die alleen leesbaar is, indien je niet al te veel toeters en bellen gebruikt (wat heel goed werkt hoor). Computers zijn veel beter in het genereren van XML dan mensen. Lost ook meteen het probleem op van of attributes er iets toe doen.

Helemaal mee eens, alleen snappen veel mensen dit niet. Het voordeel dat XML gewoon tekst is, en niet binary, is dat er gemakkelijk tools voor geschreven kunnen worden. Vaak heb je toch wel docu's nodig, maar je kunt veel meer hacken dan met een binary formaat.

[OMX2000]

[quote]
Waar attributen voor kunnen worden gebruikt is syntactische specificering van de tag (bv type, namespace etc), terwijl subtags semantische specificering van de tag voor hun rekening nemen (bv de tag Vissen met subtags Brasem, Baars en Snoek)

Wat meteen een zwakte naar boven brengt in XML: de debieliteit van de XML syntax als het gaat om '<' en '>' en speciale characters. Als je type specificaties in XML wilt opnemen in attributes, en hele namespace constructies gaat verzinnen, waarom wordt dan iets TRIESTS als het feit dat je GEEN '<' IN EEN STRING mag gebruiken niet meegenomen?

Misschien handig dat je af en toe ook op www.xml.com, de XML deviant artikelen leest. Daar worden XML perikelen besproken...

Verder: namespaces in XML, allemaal leuk, maar totaal onleesbaar voor een mens. Converteer eens een ADO recordset naar een XML DOM. het zal allemaal kloppen, maar het kost veel te veel tijd om dat te doorgronden. Het wordt al snel een onleesbare brij. Uiteraard zullen er tools komen waardoor je helemaal never nooit meer XML zult zien, wat uitstekend is want de mens werkt beter met menselijke taal en de computer werkt beter met voor de computer ontwikkelde talen, en dat lost ook meteen het geneuzel of attributes nu wel of niet moeten op: je ziet het resultaat toch niet.

Namespaces die met Schema's zijn gedefinieerd zijn heel erg goed leesbaar. Ik geef toe dat DTD's ZUIGEN. En tja dat het dumpen van ADO recordsets in XML er niet echt lekker uitziet, is niet zo erg... Je moet gewoon SQL 2000 XML resultsets uit laten spugen, en je kunt dan meteen je eigen Schema aangeven waaraan zo'n resultset moet voldoen... No Problemo...

Let wel: iedereen die roept dat je XML met de hand zou moeten schrijven is niet goed wijs: het is een beschrijving van een hierarchische structuur van semi-gerelateerde data, met een syntax die alleen leesbaar is, indien je niet al te veel toeters en bellen gebruikt (wat heel goed werkt hoor). Computers zijn veel beter in het genereren van XML dan mensen. Lost ook meteen het probleem op van of attributes er iets toe doen.

En ja ik moet toegeven dat ik er soms ook van baal dat HTML door "gewone" mensen geschreven kan worden

[mbravenboer]

Veel mensen zijn het er wel over eens, maar toch is de discussie op xml-dev weer opgelaaid. James Clark maakt een opmerking over attributen en als hij iets zegt wordt het toch wel erg serieus opgevat over het algemeen . Zo'n beetje iedereen wil gestructureerde attributen, maar ook zo'n beetje iedereen is het er overeens dat het er voorlopig wel niet van zal komen. Zelfs de @ syntax voor gestructureerde metadata/annotaties/attributen komt aan bod .