[Harish]

hello friend can you tell me that what is the difference between the xml an xhtml.
and which is better.
thanks in advance.....

[Helen]

Here's some reading for you..............
XML and XHTML

[Connetu_C]

I guess in one line you could say: "XHTML is a subset of XML geared towards marking up the structure of an average web page document". Neither is better than the other though---it just depends on what you want to do.

[mikejonesey]

xml - extensible markup language was developed as a fast and slick method to transfer data, Iv'e worked on EU projects to use this in the furniture industry for data cataloging (with vast arrays of option). This is a proven standard for such uses.

as such someone (i'm guessing at W3C) had the idea to improve the html - hyper text markup language by combining with the xml standard.

thus html+xml=xhtml

xhtml is no where near as flexible as xml so would not be a recommendation for uses such as data cataloging, whereas xml is not so proficient when used for graphical pages.

each has its benefits and disadvantages

[Badmotherz]

Let's all stop answering his inane traffic / inbound link attracting posts!!! Surely these count as spam?

[Helen]

I'm glad you said it..............

Have you checked out the portfolio? Surely if you knew this stuff, then you wouldn't have a portfolio like that.... if it is indeed theirs?!?

[mikejonesey]

talking about spam have you noticed almost 3,000 WDF members have 0 posts?

I get about 30-50 emails stuck in my mail server list per day from fake registrations

[Connetu_C]

Quote

Let's all stop answering his inane traffic / inbound link attracting posts!!! Surely these count as spam?

I agree, but for other beginners who might stumble across such a thread, it could be useful?

mikejonesey, on Dec 22 2008, 12:50, said:

xhtml is no where near as flexible as xml so would not be a recommendation for uses such as data cataloging, whereas xml is not so proficient when used for graphical pages.

Doesn't that statement nearly contradict itself, since XHTML is a subset of XML? XML+XSL (CSS in particular) should be great for web pages too, but dependence on browser compatibility is what holds it back. So rather than formatting an XML dataset (like an order confirmation or invoice) directly in the browser, we end up converting it into XHTML via XSLT on the server-side in order that it can be rendered correctly. If we knew for sure that all browsers fully supported XML+XSL, we could in theory do away with almost all HTML and XHTML since we could define our own semantically correct document structures, without waiting for new XHTML standards to emerge. Then present it with CSS, or if you then want more control over the display of the page than CSS provides, XSL-FO. The only exceptions are defining how external objects like hyperlinks, images, applets and Flash should be embedded in the XML, which would need to be well-defined so the browser can incorporate those features---but incorporating those elements from a different namespace (reserved for "browser external objects") would sort that. But then I think I'm living in fantasy land wishing widespread thorough XSL support will be available

[mikejonesey]

Connetu_C, on Dec 22 2008, 13:08, said:

I agree, but for other beginners who might stumble across such a thread, it could be useful?


Doesn't that statement nearly contradict itself, since XHTML is a subset of XML? XML+XSL (CSS in particular) should be great for web pages too, but dependence on browser compatibility is what holds it back. So rather than formatting an XML dataset (like an order confirmation or invoice) directly in the browser, we end up converting it into XHTML via XSLT on the server-side in order that it can be rendered correctly. If we knew for sure that all browsers fully supported XML+XSL, we could in theory do away with almost all HTML and XHTML since we could define our own semantically correct document structures, without waiting for new XHTML standards to emerge. Then present it with CSS, or if you then want more control over the display of the page than CSS provides, XSL-FO. The only exceptions are defining how external objects like hyperlinks, images, applets and Flash should be embedded in the XML, which would need to be well-defined so the browser can incorporate those features---but incorporating those elements from a different namespace (reserved for "browser external objects") would sort that. But then I think I'm living in fantasy land wishing widespread thorough XSL support will be available

no, xhtml is no where near as flexible as xml as you still have defined tags (although these can be edited via a dtd, you are still limited to defined elements, whereas pure old xml can have any tag anywhere )
and xml is not so proficient when used for graphical pages as browser support does not nativley support graphical dtds of the xml standard, (you would have to add a fairley large and complex dtd to the xml standard to render it as xhtml, in which case you may aswell just start off with xhtml usting the standard w3c transitional or strict dtds).

[Connetu_C]

I didn't disagree that XHTML is not as flexible as XML---it cannot be by definition that XHTML is a subset of XML. Done.

But I disagree on the other point: I say XML is just as proficient as XHTML/HTML for displaying graphical Web pages. It too can be styled with CSS or XSLT which are both supported by all major browsers, or in theory (although not widely supported as you say) any number of other modules. There are examples on How to add style to XML and Styling XML Documents. In a modern browser in standards compliance mode, these will take equal processing time as any XHTML page because the parsers work the same way in both cases.

The only advantage of XHTML over XML is the formalisation of a few external objects the browser must provide support for---namely hyperlinks via <a>, other embeds via <object>, possibly images via <img /> (for essential content only, CSS can deal with background and "eye-candy" images) and some metadata tags. This can be solved by creating a few additional elements and attributes in its own namespace---like the XHTML 2 "href" and "src" attributes, and <object>. They could then be used in any XML document, and that's a much smaller subset of content for the W3C to maintain. Then pages can be created which actually make sense in context; like this:

<news-page>
  <menu>
	<item html:href="/">Home</item>
	<item html:href="/news">News</item>
  </menu>
  <advert html:src="/images/banner.jpg" />
  <article>
	<heading>News Story title</heading>
	...
  </article>
</news-page>

Isn't that the ideal of every developer deeply concerned with semantics? It certainly makes far more sense than a load of <div>s, which is the popular consensus on how to layout pages. Quite how a browser would choose to render that aurally is another matter, but just reading the tag names aloud would make sense to me.

[mikejonesey]

is did not say "XML is just as proficient as..." i said "xml is not so proficient when used for",

please read again

[Connetu_C]

mikejonesey, on Dec 22 2008, 14:09, said:

is did not say "XML is just as proficient as..." i said "xml is not so proficient when used for",

I know that. You misread the statement, hence suggesting I was unclear, so I have edited my post to insert the words "I say".

[mikejonesey]

hmm, yea you can style xml with css, Iv'e used this to generate reports before, but I think I would prefer xhtml for styling graphical web pages as I stated in my previous post the default dtds in xhtml are the reason, styling xml to achive some of the same effects would cause code bloating from extra declarations not required in xhtml.