W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2006

[whatwg] several messages about XML syntax and HTML5

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 11 Dec 2006 00:25:27 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0612102327230.16529@dhalsim.dreamhost.com>
On Thu, 7 Dec 2006, Mike Schinkel wrote:
>
> 1.) Inserting Sam Ruby's SVG logo into HTML, for one example.

The <img> element already supports images in HTML. You can even embed 
images directly in the page with data: URIs, regardless of the format (be 
it PNG, JPEG, or SVG, for example.)


> 2.) To incorporate an RSS feed in the HTML document and have it transformed
> by XSLT. This would allow me to display headlines on my HTML pages but not
> how to duplicate my RSS feed nor do the transform on the server.

This is a solution, not a problem. One key characteristic which identifies 
a problem statement from a solution is that a problem will rarely actually 
involve naming any technologies.

If the problem was "Make it possible for documents to be syndicated", then 
just using HTML5's new semantic elements should be enough. Augmented with 
something like hAtom, and you have a complete solution.


> 3.) To embed RDF into HTML and be able to transform it visually.

Again, that's not a use case, it's a (part of a) solution. If the actual 
goal is to have metadata in the document, then HTML5's core elements and 
attributes, as well as its extension mechanisms, already allow you to do 
this. What can't you do that you need to do?


> 4.) Ability to embed Word XML into a document and transform it. This 
> would allow services to accept uploaded Word docs, export their XML, and 
> display them online.

Transforming proprietary markup into HTML is already possible and doesn't 
require anything new from HTML. Google does it with existing (non-XML) 
Word documents, for example.


> 5.) Allowing me to insert non-visible metadata about my document so it 
> can be parsed by an XML parser (to explain my use case would require 
> that I explain my entire project. I don't have time for that at the 
> moment.)

And I don't have time to address problems that people don't explain. :-)

(If you can't describe your problem in a paragraph or two, you probably 
have bigger problems, anyway.)


> > > This would allow almost ultimate flexibility moving forward and not 
> > > require an HTML6 for many things.
> >
> > Why would requiring HTML6 be a bad thing?
> 
> You say HTML5 won't have broad browser support until 2008.

No, I said that the sum total of all new browser features being introduced 
won't be interoperably implemented with a test suite for many years. If 
you want new features to be implemented, it doesn't matter if you call 
those new features HTML6 or something else, it'll still take a long time.


> > We already have such a mechanism, namely, plugins.
> 
> Two extension mechanisms are not possible?

Redundancy is always possible. Whether it is desireable is the question.


> > > And because it would be required to be valid (or at least well 
> > > formed) XML you'd give HTML publishers a chance to learn the rules 
> > > of XML.
> >
> > Why is that a good thing?
> 
> Because XML is the other important technology.

"the other important technology"? Could you elaborate?

XML is merely a metalanguage syntax. It's actually a cut down version of 
1986's SGML. There are many, many other technologies that are "the other" 
technology with more relevance to the Web, for example CSS, HTTP, 
JavaScript, the DOM, PNGs, etc. I don't see why a metalanguage syntax is 
especially important for the Web compared to those other technologies.


> > > It would also allow embedding of what I'll call "Microdirectives", 
> > > i.e. basically metadata, but that visible like Microformats.  It 
> > > would let someone publish both a human readable document and a 
> > > machine readable document.
> >
> > HTML already lets you do this. Microformats are an example of this.
> 
> I suggested this one the Microformat list and they told me under no 
> uncertain terms that Microformats needed to be visible.

Yes, visible metadata is far more likely to be kept updated than invisible 
metadata (a quick look at the Web is enough to demonstrate that).


> > 14 characters is not enough to warrant
> 
> 14 characters times every instance. There can be hundreds to thousands 
> of instances on the page. It makes creating the markup correctly very 
> difficult, and adds needlessly to page size (often exceeding Google 
> recommendations for parsable documents.)

Could you show me an example of such a page?


> > What's wrong with:
> >    $54.97 (USD)
> 
> Uh, no metadata?

What metadata is missing? The currency and amount are both present. What 
more do you need?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 10 December 2006 16:25:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:51 UTC