- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 7 Sep 2009 11:57:37 +0300
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Shelley Powers <shelleyp@burningbird.net>, public-html WG <public-html@w3.org>
On Sep 7, 2009, at 11:21, Henri Sivonen wrote: > 1) Leave RDF/XML-looking stuff non-conforming. Bad because copy- > pasting leads to a lot of errors about stuff that browsers will > ignore--just like they ignore the contents of <metadata> in XML. This is violation of our Design Principles, because it puts theoretical purity ahead of users who copy and paste. Note that Support Existing Content doesn't apply, because when you paste, you are authoring something new and Support Existing Content is about supporting stuff that's already being served out there. > 2) Perform full Namespace processing in <metadata> subtrees. Bad > because this would introduce considerable complexity in order to > shuffle around namespaces of stuff that browsers (and so far even > validators!) end up ignoring. Adding a lot of complexity to tweak > the DOM only so that it can be ignored doesn't make sense. This is a violation of our Design Principles, because it puts theoretical purity ahead of parser implementors. > 3) Leaving the DOM building as-is but proclaiming the RDF/XML- > looking stuff that infoset-wise isn't RDF/XML as conforming. Bad > because it would make authors believe that they are actually using > RDF/XML and worse because if someone wanted to consume that data as > RDF, they'd need to have dual code paths for text/html and XML (and > the DOM Consistency Design Principle is all about avoiding that > situation). This is a violation of our Design Principles, because there'd be conforming stuff that doesn't have DOM Consistency. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 7 September 2009 08:58:17 UTC