[DTD] Modularisation

[Jack McKalling]

I know there is a DTD tutorial, I've read it sometime. I also have a book about Xhtml that says someting about modularisation, but I just don't know where to start. Should I try to modify a copy of the W3C orriginal Xhtml strict DTD? Or should I start with easy tests? I am a total newbee if it is about making my own DTD, however, I understand the syntax explained in my book. If it is not too complicated :)Is it possible to apply a simple test DTD to a test document, or should it be complete? If so, how can I test my DTD? I like to build my own Xhtml, would be nice

[Jack McKalling]

Does anyone know something about this?

[justsomeguy]

Why do you want to create your own DTD anyway? The good thing about DTD is that they are standard (in theory).

[Jack McKalling]

Haven't though about that it might not be recognised in all browsers :)Good you notice it, arent they always standardly recognised, if they were made custom ? :blink:I thought it wouldn't matter if I made my own DTD, that it would just always work, if not, I'll step aside of the idea

Edited June 4, 2006 by Dan The Prof

[justsomeguy]

Well, from what I gather, the DTD tells the browser how to render the page. So I would think the syntax for describing that would be pretty complex, is there something you are using for a resource on how to do this?

[Jack McKalling]

I only know how the syntax of "DTD" goes, from what I've learned from the tutorial and my book... I haven't coded anything in it actually, so I have no clue..

[boen_robot]

Well, from what I gather, the DTD tells the browser how to render the page.

Not quite. What it tells to the browser is what nodes are valid in the document at what point.The simplest example I can think of is the Markup (HTML) validator. It validates your markup against the pointed in the drop-down menu DTD, or against the one from within the document. It's up to the other applications reading the file to decide if they are going to render the invalid elements, return an error message/template at the invalid spot, or simply not render the whole document.So if you're using let's say a server side scripting program that allows users to enter data, you can validate this data against a DTD with the script and refuse to accept it, the same way as you could refuse a string with a regular expression for example.

[Jack McKalling]

I know what DTD is for My only question actually is, what would you recommend if I was about to make my own DTD:-copy the orriginal DTD and edit it for my own use-write from scratch-don't at allAnd second, if I would write from scratch, could a halfly defined DTD work properly, only for testing uses? Say I have a DTD defining one or two elements, and the document it is attached to having that element and th eother as the root, would it work properly even there are no other elements in the DTD?And third, how can I attach my DTD to a document, or how can I attach several? I don't understand the doctype element.

[boen_robot]

Incase you didn't noticed, I was trying to explain that to justsomeguy (see the quote). As for your problem... hm...I wouldn't reinvent the wheel. Unless you're constructing another whole language which is suppose to have something new, I would advice that you don't start from scratch. That is, if we're talking about reinvention of existing DTD's- Don't.Editing the standart DTD is usefull for small corrections in order to keep your markup valid, yet have something new. The page showing this best is the style page at W3C.org. It uses a blink text as a joke, which is actually a custom DTD with a minor correction from XHTML's DTD.If you're only using a small "microformat" for your own needs only and that markup is not going to be validated and/or is going to be transformed into another natively supported by the browser format (XHTML) anyway, then there's no practical need of using DTD.If the use case in the previous post or any simmilar applies to you, you should use DTD.

[Jack McKalling]

Well, I always dreamed about having some documents like this:

<prof_community><header><titlebar>Prof-Community</titlebar>...</header><document><logo ... /><head>Welcome to the Prof-Community!<button action="skinchanger" value="orange" /><button action="skinchanger" value="green" /><button action="skinchanger" value="blue" /></head><page><menu>...</menu><main>...</main></page></document></prof_community>

[justsomeguy]

I'm sure you can do that, but it sounds like the DTD defines structure only, which means that the browser doesn't know what to do with a logo tag, or a header tag, or a document or page tag. It doesn't know how to render those. You can tell it that the logo tag is allowed inside the header tag and which attributes and events apply to it, but you can't tell it what to do with the logo tag if the browser doesn't already implement it.

[Jack McKalling]

That bothers me too :)Whenever I read the DTD lessons I thought about making a DTD my own, but how should the browser know how I want the elements to be rendered? What does a custom DTD miss compared to the standard DTD, with which browsers do know how to render things? Or how can I tell a custom DTD how to render things? Or is that a full job for CSS? I don't have any clue..In the standard DTD there are image tags, those are empty too, but the browser doesn't complain about how to render them even if I had no stylesheet... How come it would with my own DTD? *cries*[*Edit:] please excuse my English, I may sound completely stupid

Edited June 5, 2006 by Dan The Prof

[boen_robot]

The reason for which XHTML and SVG for example work in FF and Opera is that they have native support for it. In other words, they know what the author of the language meant and they know that's the language by looking at the DTD's location.So you have 3 options:1. Contact browser vendors, asking them to implement native support for your language- chances of sucess: 0.2. Create an XSLT, or a script that would transofrm your XML into something more familliar to the browser (like XHTML for starters). That's what XSLT is most often used for anyway.3. Create a completely new application that reads such files. Knowedge of C++ or other OOP language is requred. The best example of such language is X3D. It's a language made by the Web 3D consortium and it's suppose to allow 3D graphics, declared in XML syntax. There are external viewers for it and a few browser plug-ins too. Going on this road gives you many advantages, but you'll have to gain customers first.

[Jack McKalling]

So DTD is not the best option? Then, why is there such "modularisation"?Can't I 'create' my own Xhtml elements by DTD? If I am supposed to transform it back to Xhtml in that case, I'll pass for modularisation :)I thought it was mean to exist to extend the Xhtml into what the X stands for; EXTENSIBLE. As like extend it to whatever you want the markup to be. In other words, you don't recommend me using different markup than html, in Xhtml do you?

Edited June 5, 2006 by Dan The Prof

[aspnetguy]

So DTD is not the best option? Then, why is there such "modularisation"?Can't I 'create' my own Xhtml elements by DTD? If I am supposed to transform it back to Xhtml in that case, I'll pass for modularisation :)I thought it was mean to exist to extend the Xhtml into what the X stands for; EXTENSIBLE. As like extend it to whatever you want the markup to be. In other words, you don't recommend me using different markup than html, in Xhtml do you?

<{POST_SNAPBACK}>

From what I know, Yes you can extend XHTML with custom DTD but browsers will not know what to do with it.There are easier ways to create custom content. If you wanted to create your own header tags just create the cod ein a sperate file and use SSI. It may not look as cool without your new tags but it will get the job done.Until this post I was unaware of the ability to create your own DTD and see no reason to ever do so.

[Jack McKalling]

Anyway there may not be the possibility to create my own DTD, but there is for combining one, out of modules. That is called modularisation. If it doesn't work, I'll step asid from the idea and just stick to what elements I may use right now.

[justsomeguy]

I downloaded the XHTML DTD and took a look at it, and all it does it say which elements are allowed where, and which attributes apply to the elements. The browser is hard-coded on what to do with an <img> tag, the browser internally knows how to display, size, position, etc the image. The only thing the DTD says is which attributes are allowed on the image and which parent containers may contain the image.So, theoretically, you could create your own DTD and end up with a page that validates completely yet doesn't display.

[Jack McKalling]

Then there is no need for me to make my own DTD, unfortunately :)Pity, it would make my documents al lot more interesting but hey, I do want to have a working website eh

[boen_robot]

Just to clarify the term "modularization". By deviding the language into several parts, implementors can implement one module at a time or only the ones that are needed for the specific type of application. All modules are made, so every implementor's implementation could degrade well, as long as it has at least one of the modules completely implemented.Use case for a language consumer: Imagine yourself using XML as data storage. In it, you would like to format the text semantically, yet keep the presentational stuff out. Instead of defining your own tags, you could possibly make some implementation of only the text module. To do so, you would copy the text module's DTD or better yet- the text module's Schema into your language's specification. I think there's also something a bit more, but I'm not exactly sure what.A simmilar thing goes for CSS3 by the way. I myself didn't realized this term, until I heared CSS3 is devided in modules. I mean, imagine today's IE6- it supports width and height, but up until IE7, min/max-width/height weren't supported. If CSS was devided into modules from the start, MS were going to implement the whole dimensions module which (I think) includes all of the above, thus pages should degreade better. For us, CSS modularization isn't much though.