[DTD] Bestaande XHTML DTD uitbreiden* - Softwareontwikkeling

donderdag 19 juli 2007 17:12

Acties:

Topicstarter

Ik probeer de standaard XHTML 1.0 Strict DTD aan te passen met mijn eigen toevoegingen. Ik heb er al heel wat pagina's op google over gevonden en gelezen. Heel interessant allemaal, maar het is me nog niet gelukt om mijn probleem op te lossen.

Allereerst heb ik het standaard gedoe met content-type in IE. Ik krijg het op niets anders dan text/plain of text/html helaas. De validator van w3 vindt dat niet zo leuk, maar ik weet niet wat ik anders moet. Application/xml kan ook, maar dat krijg ik een foutmelding over de DTD. Application/xml+xhtml gaat gewoon downloaden, dus is sowieso hopeloos.

Maar mijn echte probleem zit hem in het extenden van bestaande (of te laden) elements. Google geeft met die keywords veel informatie, maar niet wat ik zoek. Ik wil bijvoorbeeld mijn eigen tag direct in de bestaande BODY toe staan. Handmatig alles kopieeren voor iedere situatie als deze is geen oplossing in dit geval.

Eerst maar even een stukje van 'mijn' code:

Headersetting:

PHP:

header(
        ( strpos($_SERVER['HTTP_USER_AGENT'], 'Gecko') )                    
        ?                   
       "Content-Type: application/xml; charset=UTF-8" // Firefox
            :
       "Content-Type: text/html; charset=UTF-8" // IE
    );

xhtml index.php

XML:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="./style/index.css"?>
<!DOCTYPE html PUBLIC "-//SoveNewMedia//DTD Framework Extension//EN"
          "http://www.sovenewmedia.nl/framework/admin/framework.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>
                Admin
        </title>
            </head>
    
    <body>
        
        <p>Dit is even om te testen</p>
        <bold>Blaat</bold>
        <p>
            <b>b-tag</b>
        </p>
    </body>
</html>

Dtd framework.dtd

code:

<!ELEMENT bold (#PCDATA)>
<!ENTITY % Body.content (bold)>
<!ENTITY % XHTML1-strict
        PUBLIC  "-//W3C//XHTML 1.0 Strict//EN"  
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
  %XHTML1-strict;

Meta-tag heb ik uit de xhtml gelaten, dat maakt geen verschil en zorgt alleen maar voor fouten bij het valideren. Ik heb ook dingen gelezen over 'xhtml plus target', maar dat kreeg ik niet voor elkaar om werkend te krijgen.

Probleem/fout:
Zoals het nu is krijg ik in ieder geval de foutmelding dat de '<bold>' tag niet is toegestaan waar deze nu staat. Ik wil dus de bestaande BODY type definition uitbreiden met de '<bold>' tag. In dit geval een voorbeeld, in het echte script moet dit dynamisch gaan gebeuren voor een groter aantal elements. Hopelijk weet iemand hoe dit netjes op te lossen is, en het liefst ook nog te valideren is met validator.w3.org

donderdag 19 juli 2007 18:10

Acties:

crisp

Devver

Pixelated

Ik geloof niet dat de w3 validator custom DTD's ondersteund. Sowieso kan je er ook niet vanuit gaan dat alle browsers een validating parser hebben.

Wat probeer je eigenlijk precies te bereiken? Ik kan me niet voorstellen dat je echt behoefte hebt aan een <bold> element namelijk

[ Voor 31% gewijzigd door crisp op 19-07-2007 18:12 ]

Intentionally left blank

donderdag 19 juli 2007 18:51

Acties:

Cartman!

Eens met crisp; wat is er niet goed aan de strong en h1 t/m h6 elementen?

donderdag 19 juli 2007 23:20

Acties:

Little Penguin

r0bert schreef op donderdag 19 juli 2007 @ 17:12:
Ik probeer de standaard XHTML 1.0 Strict DTD aan te passen met mijn eigen toevoegingen.

Wat je dus aan het doen bent valt het best te vergelijken met het volgende: Je aan de maximumsnelheid van 120km/uur proberen te houden met een snelheid van 140km/uur.

Het idee achter XHTML 1.0 Strict is dat alle presentatie gegeven in een stylesheet terecht gaan komen en je XHTML slechts bestaat uit semantische markup.

Allereerst heb ik het standaard gedoe met content-type in IE. Ik krijg het op niets anders dan text/plain of text/html helaas. De validator van w3 vindt dat niet zo leuk, maar ik weet niet wat ik anders moet. Application/xml kan ook, maar dat krijg ik een foutmelding over de DTD. Application/xml+xhtml gaat gewoon downloaden, dus is sowieso hopeloos.

Internet Explorer ondersteund geen XHTML, dus heb je pech als je deze -enigszins verouderde- applicatie wilt/moet ondersteunen. Wat is er overigens mis met de HTML4.01 Strict standaard? Qua semantiek zijn XHTML1.0 Strict en HTML4.01 Strict voor 99% identiek.

Verder ondersteund de W3C validator geen eigen extensies meer voor wat de DTD betreft...

[KNIP: Voorbeeld over het gebruik van een <bold> element.]

Als je dit echt van plan ben ga dan terug naar HTML4.01 Transitional en gebruik het element. Zoals al aangegeven is het idee achter (X)HTML Strict dat je juist geen presentatiecode in je markup hebt, maar dat via CSS doet.

Meta-tag heb ik uit de xhtml gelaten, dat maakt geen verschil en zorgt alleen maar voor fouten bij het valideren. Ik heb ook dingen gelezen over 'xhtml plus target', maar dat kreeg ik niet voor elkaar om werkend te krijgen.

Voor XHTML+Target kun je mijns inziens het beste (X)HTML Transitional gebruiken - die bevat qua DTD zo'n beetje alle elementen die volgens de (X)HTML standaard mogelijk zijn.

Probleem/fout:
Zoals het nu is krijg ik in ieder geval de foutmelding dat de '<bold>' tag niet is toegestaan waar deze nu staat. Ik wil dus de bestaande BODY type definition uitbreiden met de '<bold>' tag. In dit geval een voorbeeld, in het echte script moet dit dynamisch gaan gebeuren voor een groter aantal elements. Hopelijk weet iemand hoe dit netjes op te lossen is, en het liefst ook nog te valideren is met validator.w3.org

Ook dit past niet binnen XHTML Strict, als je eigen uitbreidingen wilt hebben dan zul je ook moeten accepteren dat je document NOOIT zal valideren. Als het om nieuwe elementen gaat die je dmv JavaScript/CSS/bindings van extra betekenis gaat voorzien dan zul je gewoon moeten accepteren dat je document niet valideert.

Mocht dit bedoelt zijn voor een web-applicatie die voor een bepaald bedrijf/doelgroep gemaakt is dan hoef je je volgens mij ook geen zorgen te maken over die validatie. Zorg er voor dat het werkt op de browsers die je moet ondersteunen (vaak alleen IE of IE+Fx) en laat de validatie voor wat het is.

Als je echter een normale website aan het maken bent die voor "iedereen" bedoelt is: Stop dan met het maken van uitbreidingen, want die krijg je onmogelijk werkend op alle moderne browsers (Safari [WebKit], Firefox, Camino, SeaMonkey [Gecko], IE [Trident], Opera [Presto]) om nog maar te zwijgen over browsers die geen JavaScript ondersteunen (zoals de NetSurf Browser, Lynx, etc).

vrijdag 20 juli 2007 00:10

Acties:

r0bert

Topicstarter

crisp schreef op donderdag 19 juli 2007 @ 18:10:
Ik geloof niet dat de w3 validator custom DTD's ondersteund. Sowieso kan je er ook niet vanuit gaan dat alle browsers een validating parser hebben.

Daar heb ik inderdaad ook mijn bedenkingen over, maar hij pakt mijn eigen DTD en het gedefinieerde element wel, dus het zou moeten kunnen naar mijn idee. Ik zal ook een andere validator proberen, maar denk dat daar hetzelfde uit komt, omdat het probleem van het extenden van een bestaand element nog niet opgelost is.

Wat probeer je eigenlijk precies te bereiken? Ik kan me niet voorstellen dat je echt behoefte hebt aan een <bold> element namelijk

Bold is een voorbeeld, in het echte systeem komt dit niet aan de orde. Het gaat om semantiek, als niet voor het complete web, dan wel binnen het framework. Zo zou ik een specifieke tag willen definieren, om hier in de afhankelijk ook specifiek onderscheid in te maken. Ook zou ik graag dat mijn eigen namespace valideerd naast de standaard XHTML die ik gebruik (anders moet ik alle rendering via CSS gaan definieren).

Cartman! schreef op donderdag 19 juli 2007 @ 18:51:
Eens met crisp; wat is er niet goed aan de strong en h1 t/m h6 elementen?

Niets, dat is zelfs beter in het gegeven voorbeeld natuurlijk.

Little Penguin schreef op donderdag 19 juli 2007 @ 23:20:
[...]
Wat je dus aan het doen bent valt het best te vergelijken met het volgende: Je aan de maximumsnelheid van 120km/uur proberen te houden met een snelheid van 140km/uur.

Eerder 140 km/h toe te staan, waar dat nodig is.

Het idee achter XHTML 1.0 Strict is dat alle presentatie gegeven in een stylesheet terecht gaan komen en je XHTML slechts bestaat uit semantische markup.

Scheiding van content en opmaak, da's onder andere een van de main issues waar dit probleem uit voort komt.

Internet Explorer ondersteund geen XHTML, dus heb je pech als je deze -enigszins verouderde- applicatie wilt/moet ondersteunen.

Klopt, IE negeert het. Daarom wil ik echter nog wel tegemoet treden aan de applicaties die het wél netjes ondersteunen.

Wat is er overigens mis met de HTML4.01 Strict standaard? Qua semantiek zijn XHTML1.0 Strict en HTML4.01 Strict voor 99% identiek.

Niets, daarom kies ik voor XHTML 1.0 Strict. Daar is net zo min iets mis mee?

Verder ondersteund de W3C validator geen eigen extensies meer voor wat de DTD betreft...

Mm, ok dankje. Dat is ook wat crisp dus zei. Jammer, fijn dat ik dat nu weet, pak ik een andere validator. Hij neemt trouwens wel mijn DTD mee in het valideren. Mogelijk niet voldoende

Als je dit echt van plan ben ga dan terug naar HTML4.01 Transitional en gebruik het element. Zoals al aangegeven is het idee achter (X)HTML Strict dat je juist geen presentatiecode in je markup hebt, maar dat via CSS doet.

Ok, "bold" was een slecht voorbeeld, neem <book />. kan trouwens prima in XHTML strict. Het framework is compleet gebaseerd op XML (zelfs de CSS) dus daarom kies ik o.a. voor XHTML boven HTML.

Voor XHTML+Target kun je mijns inziens het beste (X)HTML Transitional gebruiken - die bevat qua DTD zo'n beetje alle elementen die volgens de (X)HTML standaard mogelijk zijn.

Target bleek iets anders te zijn naar mijn idee. Ik dacht dat je een eigen extra target op kon geven, blijkbaar gaat het echter om software genaamd Target oid?

Ook dit past niet binnen XHTML Strict, als je eigen uitbreidingen wilt hebben dan zul je ook moeten accepteren dat je document NOOIT zal valideren. Als het om nieuwe elementen gaat die je dmv JavaScript/CSS/bindings van extra betekenis gaat voorzien dan zul je gewoon moeten accepteren dat je document niet valideert.

Ik snap niet waarom ik het niet zou kunnen valideren als ik aan mijn eigen DTD de DTD van XHTML toevoeg? Ik kan toch gewoon zelf weten wat ik met mijn DTD doe? Het gaat om een external subset, dat moet volgens mij gewoon correct zijn om te gebruiken.

Mocht dit bedoelt zijn voor een web-applicatie die voor een bepaald bedrijf/doelgroep gemaakt is dan hoef je je volgens mij ook geen zorgen te maken over die validatie. Zorg er voor dat het werkt op de browsers die je moet ondersteunen (vaak alleen IE of IE+Fx) en laat de validatie voor wat het is.

Het wordt een framework wat onder veel websites zowel backend als frontend moet gaan opereren. De websites moeten zoveel mogelijk toekomst-proof zijn voor zover dat mogelijk is (niet ver dus ;-)). Binnen het framework gebeurd de validatie volledig door middel van XML Schema/XSD en is dit ook van groot belang voor het functioneren van de applicatie. Ik heb alleen het vermoeden dat browsers in de toekomst wel gebruik gaan maken van de DTD, zoals Firefox hier nu al naar kijkt. DTD is niet mijn ding, zeker niet als ik naar XML Schema kijk. Maar aangezien het een compleet toereikend pakket moet worden, waar semantiek en validatie hoog in het vaandel staan, ben ik bang dat DTD een must is.

Als je echter een normale website aan het maken bent die voor "iedereen" bedoelt is: Stop dan met het maken van uitbreidingen, want die krijg je onmogelijk werkend op alle moderne browsers (Safari [WebKit], Firefox, Camino, SeaMonkey [Gecko], IE [Trident], Opera [Presto]) om nog maar te zwijgen over browsers die geen JavaScript ondersteunen (zoals de NetSurf Browser, Lynx, etc).

Browsers die het niet ondersteunen, zullen het (moeten) negeren. Dat browsers het niet (goed) ondersteunen, wil ik niet ten koste laten gaan van die het wel goed doen, DTD is er niets voor niets toch? Maar ik zal er nog eens goed over nadenken. Is validatie niet belangrijk met het oog op toekomstige ontwikkelingen en indexering van het web en koppelen als webservice?

vrijdag 20 juli 2007 08:52

Acties:

Cartman!

Ik vind t nog steeds n vaag verhaal. Waarom niet gewoon XML & XSLT gebruiken als je zonodig zelf tags wilt bedenken?

vrijdag 20 juli 2007 08:58

Acties:

BtM909

Watch out Guys...

Mensen, de X in XHTML staat toch voor Extensible

Het voorbeeld is misschien niet zo sterk, maar kan me qua toepassingen wel heel goed iets erbij voorstellen

Volgens mij is dit er een die wel custom DTD valideert: http://htmlhelp.com/tools/validator/customdtd.html

[ Voor 26% gewijzigd door BtM909 op 20-07-2007 09:01 ]

Ace of Base vs Charli XCX - All That She Boom Claps (RMT) | Clean Bandit vs Galantis - I'd Rather Be You (RMT)
You've moved up on my notch-list. You have 1 notch
I have a black belt in Kung Flu.

vrijdag 20 juli 2007 10:05

Acties:

Little Penguin

BtM909 schreef op vrijdag 20 juli 2007 @ 08:58:
Mensen, de X in XHTML staat toch voor Extensible

Het voorbeeld is misschien niet zo sterk, maar kan me qua toepassingen wel heel goed iets erbij voorstellen

De 'X' in XHTML staat inderdaad voor 'eXtensible', alleen zijn er bij XML (waar XHTML op gebaseerd is) dan wel regels hoe je die uitbreiding moet verwezenlijken.

De uitbreiding gebeurt door middel van namespaces, waarbij je verschillende XML namespaces gebruikt om verschillende standaarden samen te voegen. Bijvoorbeld XHTML+MathML+SVG. Je kunt dat echter geen gebruik meer maken van een DTD (validatie moet dan volgens mij via XSD's - maar daar heb ik echter geen ervaring mee).

In het document XML namespaces by example dat te vinden is op XML.com staat een voorbeeld hoe je XML namespaces moet implementeren.

Edit: Uiteraard mag je dan ook zelf een XML-taal ontwikkelen, waar je dan natuurlijk ook voor de afhandeling van de elementen in die taal moet zorgen...

[ Voor 7% gewijzigd door Little Penguin op 20-07-2007 10:08 ]

vrijdag 20 juli 2007 12:20

Acties:

r0bert

Topicstarter

Ik snap niet waarom mensen hier nou spreken over het niet mogelijk valideren? Het valideren gebeurd gewoon aan de hand van de opgegeven DTD, die de mogelijke documentstructuur beschrijft. Als ik die DTD uitbreid, en daarmee mijn document, dan moet die completere DTD het document gewoon valideren? Het klopt als er gesteld wordt dat het binnen de standaard XHTML DTD niet valideerd, maar daarom juist mijn eigen toevoegingen.

Ik vind t nog steeds n vaag verhaal. Waarom niet gewoon XML & XSLT gebruiken als je zonodig zelf tags wilt bedenken?

Dát gebeurd al. De output bestaat dus uit verschillende elementen. Ander voorbeeld, een navigatie tree. Wat vind je semantischer:

code:

<tree>
   <item type="page" />
   <item type="object">
      <item type="page" />
      <item type="popup" />
      <item type="external" />
   </item>
   <item type="page" />
</tree>

Of binnen de XHTML blijven en eigen uitbreiding niet toestaan (@BtM909 eens, waarom heet het anders extensible, dat is juist de kracht door het te combineren met XML). Zoals:

code:

<ul>
   <li onclick="functie('page');" />
   <li onclick="functie('object');">
       <ul>
             <li onclick="functie('page');" />
             <li onclick="functie('popup);" />
             <li onclick="functie('external');" />
       </ul>
   <li onclick="functie('page');" />
</ul>

Ik vind de eerste veel correcter. En om dit ook correct op te nemen, moet dit opgenomen worden in de custom DTD, waarin de standaard DTD van XHTML geinclude is. Zo valideerd het volledig, met de toevoegingen. Ik weet niet welke methode jullie netter vinden? Ik de eerste.

Little Penguin:
De 'X' in XHTML staat inderdaad voor 'eXtensible', alleen zijn er bij XML (waar XHTML op gebaseerd is) dan wel regels hoe je die uitbreiding moet verwezenlijken.

Daar hou ik me toch juist aan door de DTD? De syntax van XML verwerk ik in mijn XHTML en ik geef aan welke regels er voor mijn XML gelden in de DTD.

De uitbreiding gebeurt door middel van namespaces, waarbij je verschillende XML namespaces gebruikt om verschillende standaarden samen te voegen. Bijvoorbeld XHTML+MathML+SVG. Je kunt dat echter geen gebruik meer maken van een DTD (validatie moet dan volgens mij via XSD's - maar daar heb ik echter geen ervaring mee).

Namespaces gebruik ik inderdaad ook voor de uitbreidingen, maar die kan ik toch prima in mijn DTD opnemen? Daar is het volgens mij juist voor.

XSD/XML Schema gebruik ik reeds, maar dan voor serverside validatie. De DTD is naar applicaties toe die dit gebruiken. Dat kan een browsers zijn of een andere service die wil weten wat het kan verwachten (daar is overigens ook SOAP/WSDL e.d. voor).

Een van mijn uitbreiding is phpframeworkxml, met namespace pfwx. Door dit framework wil ik afhandeling van de nieuwe elementen laten gebeuren en ook standaard styling hierop toepassen. Zo pas ik nu eigen XForms en XLink toe en XCSL (Extensible Cascading Styling Language). Dat laatste heb ik ontwikkeld om stylesheets in de vorm van XML te kunnen opstellen en te bewerken, welkgeen trouwens stukken beter dan de standaard CSS werkt.

Nu wil ik om dit alles netjes te houden het dus wel in de DTD beschrijven. Het enige probleem hierbij is dat ik moet aangeven voor het BODY element dat daarin naast de standaard elementen, ook een extra element gebruikt kan worden. Ik moet dus weten hoe ik een element append aan deze bestaande reeks.

vrijdag 20 juli 2007 12:41

Acties:

Little Penguin

r0bert schreef op vrijdag 20 juli 2007 @ 12:20:
Dát gebeurd al. De output bestaat dus uit verschillende elementen. Ander voorbeeld, een navigatie tree. Wat vind je semantischer:
code:
1
2
3
4
5
6
7
8
9
<tree>
 <item type="page" />
 <item type="object">
 <item type="page" />
 <item type="popup" />
 <item type="external" />
 </item>
 <item type="page" />
</tree>
Of binnen de XHTML blijven en eigen uitbreiding niet toestaan (@BtM909 eens, waarom heet het anders extensible, dat is juist de kracht door het te combineren met XML). Zoals:
code:
1
2
3
4
5
6
7
8
9
10
<ul>
 <li onclick="functie('page');" />
 <li onclick="functie('object');">
 <ul>
 <li onclick="functie('page');" />
 <li onclick="functie('popup);" />
 <li onclick="functie('external');" />
 </ul>
 <li onclick="functie('page');" />
</ul>
Ik vind de eerste veel correcter. En om dit ook correct op te nemen, moet dit opgenomen worden in de custom DTD, waarin de standaard DTD van XHTML geinclude is. Zo valideerd het volledig, met de toevoegingen. Ik weet niet welke methode jullie netter vinden? Ik de eerste.

Die eigen semantiek heeft alleen zin als deze ook begrepen wordt door andere applicaties (op het internet), eigen uitbreidingen worden echter niet begrepen.

Voor een interne webapplicatie maakt het helemaal niet uit of het semantisch is, en is de 2e optie (li,ul) in elk geval sneller omdat er geen extra scripting/translations nodig is...

Daar hou ik me toch juist aan door de DTD? De syntax van XML verwerk ik in mijn XHTML en ik geef aan welke regels er voor mijn XML gelden in de DTD.

Namespaces gebruik ik inderdaad ook voor de uitbreidingen, maar die kan ik toch prima in mijn DTD opnemen? Daar is het volgens mij juist voor.

De DTD definitie is een erfenis van de SGML markup taal, voor XML is het echter de bedoeling om XSD te gebruiken. DTDs ondersteunen namelijk helemaal geen namespaces...

[...] De DTD is naar applicaties toe die dit gebruiken. Dat kan een browsers zijn of een andere service die wil weten wat het kan verwachten (daar is overigens ook SOAP/WSDL e.d. voor).

Het enige dat een browser met 't DOCTYPE doet is het selecteren van de rendermode (standards of quirks)

[...]
Nu wil ik om dit alles netjes te houden het dus wel in de DTD beschrijven. Het enige probleem hierbij is dat ik moet aangeven voor het BODY element dat daarin naast de standaard elementen, ook een extra element gebruikt kan worden. Ik moet dus weten hoe ik een element append aan deze bestaande reeks.

Volgens mij kun je het best alles omzetten naar XSDs en daarna zelf met een lokale XML/XSD validator controleren of je document aan je zelfbedachte standaarden voldoet...

vrijdag 20 juli 2007 12:50

Acties:

Verwijderd

r0bert schreef op vrijdag 20 juli 2007 @ 12:20:

Dát gebeurd al. De output bestaat dus uit verschillende elementen. Ander voorbeeld, een navigatie tree. Wat vind je semantischer:

Volgens mij ben je veel te ver doorgeschoten met je "semantischer". HTML is HTML, XHTML is grof gezegd HTML met XML syntax. Van HTML elementen is bekend waar ze voor dienen. Het is beschreven, en dus hebben die elementen een bepaalde betekenis. En dat is waar dat hele "semantisch correct" op slaat. Als je je eigen elementen toevoegt, weet jij misschien wat dat element betekent, maar zoekmachines kunnen er niet echt iets uit afleiden. Schakel je intuïtie uit, benader alles logisch.

Of binnen de XHTML blijven en eigen uitbreiding niet toestaan (@BtM909 eens, waarom heet het anders extensible, dat is juist de kracht door het te combineren met XML). Zoals:

Ik vind de eerste veel correcter. En om dit ook correct op te nemen, moet dit opgenomen worden in de custom DTD, waarin de standaard DTD van XHTML geinclude is. Zo valideerd het volledig, met de toevoegingen. Ik weet niet welke methode jullie netter vinden? Ik de eerste.

Ik niet. Daar kan de buitenwereld niets mee. Als je intern iets wilt doen met een zelfbedachte XML syntax. ga vooral je gang. Maar schrijf dan even een XSLT stylesheet waarmee het transformeert naar (X)HTML dat iedereen begrijpt.

Daar hou ik me toch juist aan door de DTD? De syntax van XML verwerk ik in mijn XHTML en ik geef aan welke regels er voor mijn XML gelden in de DTD.

Maar voor machines heeft jouw code geen enkele semantische waarde.

Namespaces gebruik ik inderdaad ook voor de uitbreidingen, maar die kan ik toch prima in mijn DTD opnemen? Daar is het volgens mij juist voor.

Dat klopt. Maar ze beschrijven nog steeds alleen de middelen, en niet het doel.

Een van mijn uitbreiding is phpframeworkxml, met namespace pfwx. Door dit framework wil ik afhandeling van de nieuwe elementen laten gebeuren en ook standaard styling hierop toepassen. Zo pas ik nu eigen XForms en XLink toe en XCSL (Extensible Cascading Styling Language). Dat laatste heb ik ontwikkeld om stylesheets in de vorm van XML te kunnen opstellen en te bewerken, welkgeen trouwens stukken beter dan de standaard CSS werkt.

Wat jij wilt. Ik denk dat je de grip op de realiteit een beetje aan het verliezen bent, en dat je overdesignt.

Nu wil ik om dit alles netjes te houden het dus wel in de DTD beschrijven. Het enige probleem hierbij is dat ik moet aangeven voor het BODY element dat daarin naast de standaard elementen, ook een extra element gebruikt kan worden. Ik moet dus weten hoe ik een element append aan deze bestaande reeks.

Dat kan niet zomaar, je zult volgens mij een compleet nieuwe DTD moeten maken.

vrijdag 20 juli 2007 12:56

Acties:

r0bert

Topicstarter

Little Penguin schreef op vrijdag 20 juli 2007 @ 12:41:
[...]

Die eigen semantiek heeft alleen zin als deze ook begrepen wordt door andere applicaties (op het internet), eigen uitbreidingen worden echter niet begrepen.

Voor een interne webapplicatie maakt het helemaal niet uit of het semantisch is, en is de 2e optie (li,ul) in elk geval sneller omdat er geen extra scripting/translations nodig is...

Dat ben ik niet helemaal met je eens. De semantiek is daar net zo belangrijk, al is het maar voor de samenhang en begrijpbaarheid van het framework. Applicaties moeten gaan communiceren hiermee, dat is zeker de bedoeling.

En dat methode twee sneller is weet ik niet, maar handiger in ieder geval niet. Ik kan er gewoon styling op los laten, net als op een andere XHTML-element. De scripting gaat zelfs sneller, omdat ik alles via custom attributen kan doen ipv alles in de XHTML validatie te moeten proppen (met id's, scripts die het extracten etc.)

De DTD definitie is een erfenis van de SGML markup taal, voor XML is het echter de bedoeling om XSD te gebruiken. DTDs ondersteunen namelijk helemaal geen namespaces...

Ok, DTD is dus 'uit'? Want ik moet eerlijk zeggen dat ik er zeker geen fan van ben. Het is ook de uitzondering binnen mijn applicatie, de rest (behalve het programmeergedeelte zelf) is allemaal valid xml.

Volgens internetbronnen (google) kun je in je DTD gewoon je namespace opnemen als in ns:elm.

Het enige dat een browser met 't DOCTYPE doet is het selecteren van de rendermode (standards of quirks)

Het gaat niet alleen om browsers, maar dat is natuurlijk wel belangrijk. Als een browser daardoor sneller uit de voeten kan, wil ik het er wel bij gaan maken. Maar overbodig is overbodig natuurlijk.

Volgens mij kun je het best alles omzetten naar XSDs en daarna zelf met een lokale XML/XSD validator controleren of je document aan je zelfbedachte standaarden voldoet...

Ja, XSD/XML Schema gebruik ik serverside al en dat wordt ook gebruikt om te valideren. De achterliggende functie is om input van gebruikers te valideren op juistheid en toepasbaarheid binnen het framework.

Maar wat ik dus concludeer uit dit verhaal is dat de gehele hype over validatie al achterhaalt zou zijn?

vrijdag 20 juli 2007 13:25

Acties:

Verwijderd

voor een browser doet semantiek ook helemaal niet terzake, een browser hangt helemaal geen interpretatie aan welk element dan ook (wat uitzonderingen daargelaten), of je nou een , of een eigen bedacht element in je xhtml stopt maakt voor de browser niets uit.

Zoekmachines kunnen alleen wat doen met elementen binnen de xhtml namespace (ruwweg), eigen bedachte elementen voegen daarvoor niets toe, maar halen ook zeker niets weg.

Als je zelf een applicatie hebt die iets doet met he xhtml en daar wil je extra functionaliteit in bouwen buiten de xhtml namespace, kan ik me heel goed voorstellen dat je extra elementen in je xhtml opneemt. Anders zou je weer iets als content negotiation moeten doen voor die applicaties, lijkt me een beetje loos.

intern xml gebruiken en dat transformeren naar xhtml is juist overkill vind ik, juist als het maar om een beperkt aantal elementen gaat. xhtml is al xml, dus waarom zou je een compleet nieuwe namespace gaan opzetten voor dingen die prima in xhtml te schrijven zijn? dus dan je paar extra dingen gewoon in de xhtml

voor het allermooist zou je nog een xslt over uitgebreide xhtml kunnen gooien om de niet-xhtml namespace elementen eruit te halen en "puur" xhtml aanbieden. Maar waarom zou je dat doen? je haalt dan informatie weg en de interpretatie verandert er ook niet door voor machines die alleen de xhtml namespace kennen. Door die extra elementen erin te laten zitten houd je iig de mogelijkheid voor anderen om je extra elementen te benutten

wat je iig niet moet doen is zelf elementen gaan verzinnen wat prima in een bestaande namespace (iha xhtml) te beschrijven is. Iedereen verzint overal maar eigen xmltaaltjes voor, maar dat moet imho zoveel mogelijk voorkomen worden. Gebruik nou gewoon bestaande ontologies.

vrijdag 20 juli 2007 13:38

Acties:

r0bert

Topicstarter

Verwijderd schreef op vrijdag 20 juli 2007 @ 12:50:
Volgens mij ben je veel te ver doorgeschoten met je "semantischer". HTML is HTML, XHTML is grof gezegd HTML met XML syntax. Van HTML elementen is bekend waar ze voor dienen. Het is beschreven, en dus hebben die elementen een bepaalde betekenis. En dat is waar dat hele "semantisch correct" op slaat. Als je je eigen elementen toevoegt, weet jij misschien wat dat element betekent, maar zoekmachines kunnen er niet echt iets uit afleiden. Schakel je intuïtie uit, benader alles logisch.

Semantiek is, zoals wikipedia het omschrijft: "De semantiek houdt zich bezig met de betekenis van symbolen (zoals de woorden in een taal)." Ik zou niet weten waarom dat zich zou beperken tot XHTML. Maar misschien moet je het breder zien in de trant van validiteit. Als je een navigatietree beschrijft, moet je dat niet beschrijven met "person"-tags en naar mijn mening is het ook geen list. Ik snap:

Ik niet. Daar kan de buitenwereld niets mee. Als je intern iets wilt doen met een zelfbedachte XML syntax. ga vooral je gang. Maar schrijf dan even een XSLT stylesheet waarmee het transformeert naar (X)HTML dat iedereen begrijpt.

.. dat de buitenwereld daar niets mee kan en dat is dus ook waar de schoen wringt. Door me aan die standaarden te houden en een list te gebruiken voor een navigatie etc, vind ik mijzelf een hypocriet ten opzichte van semantiek als ik me beperk tot wat er binnen XHTML is gedefinieerd. Je laatste punt snap ik echter ook wel weer, aangezien je zelf onmogelijk standaard voor browsers kunt gaan brengen.

Dat punt, maakt het toepassen van semantiek op eigen uitbreidingen inderdaad onmogelijk voor de browsers, maar dat wil niet zeggen dat het niet meer hoeft te valideren. Ik vind dat echter wel erg jammer, aangezien het hele oogmerk van extensibility daardoor deels verloren gaat. Ik zie juist wel de voordelen ervan en daarom is serverside hier volledig van geprofiteerd. Clientside is dat echter vrij moeilijk, omdat we zo afhankelijk zijn van die browsers. Jammer.

Maar voor machines heeft jouw code geen enkele semantische waarde.

Dat is niet correct. Een machine die weet wat het document voorsteld, kan er prima mee om gaan. Dat is dan ook precies de bedoeling, clientside vormen de browsers een uitzondering.

Dat klopt. Maar ze beschrijven nog steeds alleen de middelen, en niet het doel.

Ok?

Wat jij wilt. Ik denk dat je de grip op de realiteit een beetje aan het verliezen bent, en dat je overdesignt.

Ik denk van niet, waarom? Serverside implementeren van XLink, XForms en XCSL werkt ideaal en voorkomt afhankelijkheid van crossbrowserfunctionaliteiten aan de clientside. Maar ik sta open voor kritiek waarom dit overdesigned is...

Dat kan niet zomaar, je zult volgens mij een compleet nieuwe DTD moeten maken.

Dat is eigenlijk het enige waar ik in dit topic naar op zoek was

Ik kan inderdaad de XHTML DTD kopieren, maar dan zal ik bij XHTML 1.1+ weer de dingen moeten aanpassen. Het leek me flexibeler om instelbare DTD's te gebruiken.

Maar even wat ik tot nu toe in ieder geval duidelijk heb.

Het toevoegen van childs aan een bestaand element in een DTD is blijkbaar niet mogelijk (niet extensible)
Eigen elementen naar de browser toe presenteren is not done.
Webservices kunnen zich rustig beperken tot XSD, DTD is totaal overbodig. Eigen tags zijn hier geen probleem.
DTD is inmiddels achterhaalt en zal vervangen worden door XSD?

Compleet en correct?

vrijdag 20 juli 2007 13:44

Acties:

Little Penguin

r0bert schreef op vrijdag 20 juli 2007 @ 12:56:
Ok, DTD is dus 'uit'? Want ik moet eerlijk zeggen dat ik er zeker geen fan van ben. Het is ook de uitzondering binnen mijn applicatie, de rest (behalve het programmeergedeelte zelf) is allemaal valid xml.

De DTD zijn nog steeds relevant, maar alleen als je een normale internet site maakt - waarbij de relevantie dan met name van toepassing is t.o.v. het selecteren van de rendermode en natuurlijk voor de validatie door de gebruiker dmv de W3C validator (waarbij een validerende site een goede indruk achter laat bij de techneuten

)

Voor een webapplicatie is de DTD mijns inziens een stuk minder relevant...

[...]
Het gaat niet alleen om browsers, maar dat is natuurlijk wel belangrijk. Als een browser daardoor sneller uit de voeten kan, wil ik het er wel bij gaan maken. Maar overbodig is overbodig natuurlijk.

Wat ik mij dan wel afvraag is het nut van de keus voor XHTML als je toch voor een groot deel je eigen markup kiest...

[...]
Ja, XSD/XML Schema gebruik ik serverside al en dat wordt ook gebruikt om te valideren. De achterliggende functie is om input van gebruikers te valideren op juistheid en toepasbaarheid binnen het framework.

Die invoer kun je toch ook valideren t.o.v. je eigen XSD/XML Schema? Ik zie hierbij nog steeds geen toegevoegde waarde van een DTD met eigen aanvullingen...

Maar wat ik dus concludeer uit dit verhaal is dat de gehele hype over validatie al achterhaalt zou zijn?

Validatie is niet per definitie achterhaald (voor internetsites) en bij XML is het wel degelijk nodig om er voor te zorgen dat het totale document 'well formed' blijft...

Maar valideren t.o.v. XHTML Strict+aanpassingen voor een webapplicatie is niet erg zinnig als je daarna alsnog een validatieslag t.o.v. XSD/XML Schema gaat uitvoeren.

Overigens, nog een opmerking t.o.v. XHTML en Internet Exploer:
IE ondersteund geen XHTML en zul je dus zelf voor alle XHTML styling moeten zorgen en natuurlijk een stylesheet definitie aan je document toe moeten voegen...

vrijdag 20 juli 2007 13:46

Acties:

r0bert

Topicstarter

Verwijderd schreef op vrijdag 20 juli 2007 @ 13:25:
Als je zelf een applicatie hebt die iets doet met he xhtml en daar wil je extra functionaliteit in bouwen buiten de xhtml namespace, kan ik me heel goed voorstellen dat je extra elementen in je xhtml opneemt. Anders zou je weer iets als content negotiation moeten doen voor die applicaties, lijkt me een beetje loos.

Ja, dat is dus waar de afhankelijkheid van de browser blijkjbaar een erg grote rol speelt. 'Content negotiation' is iets waar je in dat geval toch niet onderuitkomt denk ik.

intern xml gebruiken en dat transformeren naar xhtml is juist overkill vind ik, juist als het maar om een beperkt aantal elementen gaat. xhtml is al xml, dus waarom zou je een compleet nieuwe namespace gaan opzetten voor dingen die prima in xhtml te schrijven zijn? dus dan je paar extra dingen gewoon in de xhtml

voor het allermooist zou je nog een xslt over uitgebreide xhtml kunnen gooien om de niet-xhtml namespace elementen eruit te halen en "puur" xhtml aanbieden. Maar waarom zou je dat doen? je haalt dan informatie weg en de interpretatie verandert er ook niet door voor machines die alleen de xhtml namespace kennen. Door die extra elementen erin te laten zitten houd je iig de mogelijkheid voor anderen om je extra elementen te benutten

De scheiding tussen XHTML en eigen XML is op zich niet slecht, daar blijft het overzichtelijk door. Het gebruikt van een extra sheet om de content alsnog om te zetten naar begrijpbare content voor specifieke applicaties is zeker handig. In simpelere gevallen zal dat al meteen bij de eerste transformatie gebeuren. In andere gevallen gebruik ik juist de XSLT om eerst de documenten te structureren in XML. De stap waar het probleem nu ligt is eigenlijk al de 'content negotiation'. Zo zal ik aparte sheets moeten maken voor XHTML en WML. Het voordeel is hiervan dat je jezelf ook weer een bepaalde vrijheid toeeigent omdat je JUIST naar verschillende applicaties kan porten. Je kunt je XML naar Excel schrijven, Word (of een niet MS programma), naar WML voor op een mobiel, misschien zelfs wat graphics in SVG.

wat je iig niet moet doen is zelf elementen gaan verzinnen wat prima in een bestaande namespace (iha xhtml) te beschrijven is. Iedereen verzint overal maar eigen xmltaaltjes voor, maar dat moet imho zoveel mogelijk voorkomen worden. Gebruik nou gewoon bestaande ontologies.

Die wildgroei ben ik het inderdaad mee eens. Dat komt wel een beetje overheen met wat Cheetah zei om eigen namespace e.d. gewoon zoveel mogelijk te beperken tot intern/eigen gebruik (ook naar 'machines' die daar mee om kunnen gaan)

Edit:
Nog wat bronnen:
"DTD's zijn de oudste methode, deze methode is overgenomen van SGML, de stamvader van HTML en XML. Schema's hebben het voordeel boven DTD's dat deze zelf in een XML-taal worden beschreven, en dat zij meer keus bieden op het gebied an datatypen. Er zijn echter nog niet veel tools die volgens de Schema standaard valideren."
Bron

'Zuivere' XML-server leeft

Wildgroei in XML-vocabulaires schreeuwt om afstemming

XML voor managers (simpeler)

Buzzwords XML (toffe illustratie)

[ Voor 12% gewijzigd door r0bert op 20-07-2007 14:20 ]

vrijdag 20 juli 2007 13:52

Acties:

r0bert

Topicstarter

Little Penguin schreef op vrijdag 20 juli 2007 @ 13:44:
De DTD zijn nog steeds relevant, maar alleen als je een normale internet site maakt - waarbij de relevantie dan met name van toepassing is t.o.v. het selecteren van de rendermode en natuurlijk voor de validatie door de gebruiker dmv de W3C validator (waarbij een validerende site een goede indruk achter laat bij de techneuten )

Voor een webapplicatie is de DTD mijns inziens een stuk minder relevant...

Ok, daar kan ik het geloof ik wel mee eens zijn. De beschrijving in XSD vind ik veel correcter. Het beschrijven van de regels voor een document heeft natuurlijk wél toegevoegde waarde, de vorm van DTD niet.

Wat ik mij dan wel afvraag is het nut van de keus voor XHTML als je toch voor een groot deel je eigen markup kiest...

Om bestaande semantiek wel over te nemen, maar deze alleen wel uit te breiden. Maar zie ook eerdere reacties over het probleem hiermee met browsers idd.

Die invoer kun je toch ook valideren t.o.v. je eigen XSD/XML Schema? Ik zie hierbij nog steeds geen toegevoegde waarde van een DTD met eigen aanvullingen...

Correct. DTD was in mijn ogen een must i.v.m. mogelijkheid tot valideren. Blijkbaar is dat helemaal geen issue.

Validatie is niet per definitie achterhaald (voor internetsites) en bij XML is het wel degelijk nodig om er voor te zorgen dat het totale document 'well formed' blijft...

Inderdaad, de vorm van DTD misschien hooguit. Validatie en beschrijven van documentstructuur heeft daarnaast nog wel gigantische voordelen (en webservices kunnen niet zonder natuurlijk).

Maar valideren t.o.v. XHTML Strict+aanpassingen voor een webapplicatie is niet erg zinnig als je daarna alsnog een validatieslag t.o.v. XSD/XML Schema gaat uitvoeren.

Daarvoor, maar dan is het inderdaad dubbelop. Het was ook meer een service naar applicaties toe die dat gebruiken (achteraf blijkbaar geen).

Overigens, nog een opmerking t.o.v. XHTML en Internet Exploer:
IE ondersteund geen XHTML en zul je dus zelf voor alle XHTML styling moeten zorgen en natuurlijk een stylesheet definitie aan je document toe moeten voegen...

IE is inderdaad afwijkend, maar door het als text/html te versturen en wel een <?xml?> te gebruiken, gaat het ook wel goed genoeg. Dat is IE's probleem

Thanks voor de info iig (geldt natuurlijk voor iedereen in het topic

)

Edit:
Kan iemand mij nog een voordeel van DTD noemen, anders laat ik het gewoon schieten en gebruik ik alleen nog XSD.

vrijdag 20 juli 2007 14:51

Acties:

r0bert

Topicstarter

Verwijderd schreef op vrijdag 20 juli 2007 @ 13:25:
Als je zelf een applicatie hebt die iets doet met he xhtml en daar wil je extra functionaliteit in bouwen buiten de xhtml namespace, kan ik me heel goed voorstellen dat je extra elementen in je xhtml opneemt. Anders zou je weer iets als content negotiation moeten doen voor die applicaties, lijkt me een beetje loos.

intern xml gebruiken en dat transformeren naar xhtml is juist overkill vind ik, juist als het maar om een beperkt aantal elementen gaat. xhtml is al xml, dus waarom zou je een compleet nieuwe namespace gaan opzetten voor dingen die prima in xhtml te schrijven zijn? dus dan je paar extra dingen gewoon in de xhtml

voor het allermooist zou je nog een xslt over uitgebreide xhtml kunnen gooien om de niet-xhtml namespace elementen eruit te halen en "puur" xhtml aanbieden. Maar waarom zou je dat doen? je haalt dan informatie weg en de interpretatie verandert er ook niet door voor machines die alleen de xhtml namespace kennen. Door die extra elementen erin te laten zitten houd je iig de mogelijkheid voor anderen om je extra elementen te benutten

Ik heb hier nog eens wat verder over nagedacht en denk dat dit wat betreft semantiek een hele belangrijke overgang is. Semantiek in eigen bedachte elementen is zeker van belang, voor een goed functioneren intern. Publiekelijk zal niet iedere applicatie het begrijpen, maar dat hoeft ook niet.

De stap source/proces -> xml genereert daarmee een XML met semantische elementen (die dus een betekenis hebben binnen de gedef. namespace). Zonder semantiek is de laag die mophor aanhaalt, niet of moeilijk te creeeren. Wil je een dynamische laag maken die de XML omzet naar XHTML, één die het omzet naar WML, één die het omzet naar SVG en weer een ander naar OpenXML, dan zal duidelijk moeten zijn wat de semantiek van ieder element is.

Mooist zou zijn als je de XML zo kon gebruiken en weergeven. Naar applicaties toe is dat onmogelijk als ze de semantiek van die XML niet begrijpen. Het ideaal zou dus zijn om XML met semantiek naar een applicatie te sturen, maar in werkelijkheid moet je die semantiek blijkbaar afdwingen door gebruik te maken van XHTML e.d. De laatste stap lijkt me dus niet te vermijden en eigenlijk ook best een nuttige toepassing, wanneer deze dynamisch kan worden toegepast (weet wat het moet doen).

Ik ga er eens mee stoeien. Ik heb trouwens gegoogled naar voordelen van DTD's maar kan ze niet vinden, dus ik denk dat mijn vraag 'beantwoord' is met niet mogelijk en niet nodig. De discussie mag van mij natuurlijk best voortgaan

vrijdag 20 juli 2007 15:43

Acties:

Little Penguin

r0bert schreef op vrijdag 20 juli 2007 @ 13:52:
IE is inderdaad afwijkend, maar door het als text/html te versturen en wel een <?xml?> te gebruiken, gaat het ook wel goed genoeg. Dat is IE's probleem Thanks voor de info iig (geldt natuurlijk voor iedereen in het topic )

Ik neem aan dat je dan ook realiseerd dat IE de pagina als HTML (tagsoup) zal interpreteren en niet als een XML pagina? Als dat geen probleem is dan zou ik me verder geen zorgen maken - of gewoon vragen of de gebruikers willen upgraden naar een browser die wel XHTML ondersteunt

Edit:
Kan iemand mij nog een voordeel van DTD noemen, anders laat ik het gewoon schieten en gebruik ik alleen nog XSD.

DTD's hebben niet echt voordelen, het enige voordeel van een correct DOCTYPE is dat je de browser in standards mode dwingt (waarbij de verschillen tussen de diverse browsers afnemen), maar dat kun je ook bereiken door gebruik te maken van het HTML5 DOCTYPE:

code:

1	<!DOCTYPE html>

Bron: DOCTYPE of HTML5

vrijdag 20 juli 2007 15:50

Acties:

r0bert

Topicstarter

Little Penguin schreef op vrijdag 20 juli 2007 @ 15:43:
Ik neem aan dat je dan ook realiseerd dat IE de pagina als HTML (tagsoup) zal interpreteren en niet als een XML pagina? Als dat geen probleem is dan zou ik me verder geen zorgen maken - of gewoon vragen of de gebruikers willen upgraden naar een browser die wel XHTML ondersteunt

Ja, ik vind het ook jammer dat het niet goed ondersteund wordt, maar zelfs met allerlei hacks is het volgens mij niet te doen. Eigenlijk is het hun probleem, maar daarmee wordt het natuurlijk mijn probleem. Ik denk dat je voorstel inderdaad het max. is van wat we eraan kunnen doen.

DTD's hebben niet echt voordelen, het enige voordeel van een correct DOCTYPE is dat je de browser in standards mode dwingt (waarbij de verschillen tussen de diverse browsers afnemen), maar dat kun je ook bereiken door gebruik te maken van het HTML5 DOCTYPE:
code:
1
<!DOCTYPE html>
Bron: DOCTYPE of HTML5

Ok, de validatie zelf is dus in geen geval van belang. Ook buiten de browsers niet snap ik nu?

Goede link trouwens, alleen ik snap niet waarom ik nou voor HTML moet gaan in plaats van XHTML (aangezien alles aan XML richtlijnen moet voldoen binnen het framework). Dat is vanwege IE, of gewoon een persoonlijke voorkeur?

vrijdag 20 juli 2007 20:13

Acties:

Little Penguin

r0bert schreef op vrijdag 20 juli 2007 @ 15:50:
[...]
Ok, de validatie zelf is dus in geen geval van belang. Ook buiten de browsers niet snap ik nu?

Als je al op een andere manier voor validatie zorgt dan is de DTD inderdaad niet echt belangrijk - voor een normale website geldt dat natuurlijk niet. Op een normale website moet je gewoon kiezen voor een (X)HTML standaard en dat ook goed aangeven, maar meer dan informatie is het niet - behalve voor de W3C validator.

Goede link trouwens, alleen ik snap niet waarom ik nou voor HTML moet gaan in plaats van XHTML (aangezien alles aan XML richtlijnen moet voldoen binnen het framework). Dat is vanwege IE, of gewoon een persoonlijke voorkeur?

Het enige voordeel van XHTML boven HTML voor websites, dat is dat je XHTML kunt uitbreiden met andere XHTML standaarden en zo een document kan maken dat XHTML, SVG en MathML (om een paar standaarden te noemen) bevat. Voor dagelijk gebruik wordt HTML echter breder ondersteund en heeft ook mijn persoonlijke voorkeur voor websites en webapplicaties.

In dit geval is de keuze voor HTML echter ook mede ingegeven door het feit dat IE helemaal geen XHTML ondersteuning bevat...

Pagina: 1

Reageer