nicht angemeldet
Hi,
Und ich schwanke dabei zwischen 2 Polen:
klingt nach einer Meinungsumfrage... also gibt's im folgenden auch nur meine Meinung :-)
- Einfache Bedienung für die XML-Schreiberlinge
Hierzu werden Tools benutzt.
oder sollte man ihnen eine (umfassende, vorher durchdiskutierte) begrenzte Menge an gültigen Werten, Elementen vorschreiben.
Oder. Dadurch ist das Konzept auch durchdachter, was Fehler minimiert.
Wobei Planung natürlich nur der Ersatz des Fehlers durch den Irrtum darstellt :-)
Nachteil: Jeder kocht seine eigene Suppe, und das einheitliche Erscheinungsbild geht den Bach runter.
Weiterer Nachteil: Fehler (z.B. Tipp-) werden nicht erkannt. Bei einem strikten DTD crasht es spätestens zur Compiletime.
Gibts da einen Kompromiss, oder muss man das von Fall zu Fall selber abwägen, was nun gscheiter ist?
Sicher kannst Du auch bei einigen Attributen davon ausgehen, daß die Liste permanent erweitert wird, was u.U. die unspezifizierte Variante vorteilhaft macht. Wenn Du aber nur ein begrenztes Set möglicher Werte absiehst, dann solltest Du dieses auch definieren.
Und thematisch dazupassend: Ist es überhaupt sinnvoll xml für nur leicht strukturierte Daten zu verwenden?
Kommt drauf an, wie "leicht strukturiert" die Daten sind, und was Du mit ihnen machen willst. Wir exportieren auch gelegentlich DB-Tabellen als (eindimensionales) XML-File.
Ich verwende derzeit eine ausgewählte Teilmenge von HTML-Elementen,
Hm, das ist nicht unbedingt positiv... wenn auch nicht zwingend negativ :-)
Wäre es ev. zu überlegen, meine "selbstgebastelten HTML-Elemente" rauszunehmen, und stattdessen gleich den ganzen HTML4-Standard in einem Namespace zu erlauben?
HTML hat einen ganz speziellen Anwendungs-Ansatz. Wenn dieser auf Deine Daten auch anzuwenden ist, kannst Du natürlich versuchen, HTML zu verwenden - wobei Du dann vielleicht XHTML bevorzugen solltest. Wenn Du hingegen bestimmte Daten unterscheidbar speichern möchtest, würde ich ehrlich gesagt von HTML ganz abgehen und etwa <link> anstatt <a> verwenden.
Cheatah