namespaces-considered-harmful - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:30:49Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:30, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~ namespaces considered harmful ~~</entry-title>~~		{{DISPLAYTITLE: namespaces considered harmful }}

	In particular namespaces for '''content''' are considered harmful (e.g. XML namespaces, QNames in attributes etc.). Namespaces for code is outside the bounds of the topic of this page.		In particular namespaces for '''content''' are considered harmful (e.g. XML namespaces, QNames in attributes etc.). Namespaces for code is outside the bounds of the topic of this page.

Tantek: add misconceptions section, scope what kind of scability (if any) they're good for, basically, experiments (not standards)

2013-07-01T23:27:16Z

add misconceptions section, scope what kind of scability (if any) they're good for, basically, experiments (not standards)

← Older revision		Revision as of 23:27, 1 July 2013
Line 95:		Line 95:

	Once again, we found that even prefixing for this specific case was unnecessary in practice.		Once again, we found that even prefixing for this specific case was unnecessary in practice.

			== misconceptions ==
			=== fairly solid namespace ===
			''(x) is a fairly solid namespace.''

			There's no such thing as a "solid" namespace. Perhaps only "solid" in the sense of a wall that gets in the way of interoperability. See silos above.

			=== namespaces good for scalability ===
			''Decentralization using namespaces is also good for scalability.''

			Namespaces just enable scalability of divergence - which is contrary / anathema to standardization and communication.

			Though they're probably ok for experiments, and scalability in the number of different experiments being performed.

			E.g. <abbr><dfn>XML</dfn></abbr> would have made more sense if it was thought of as "eXperiment Markup Language".

	== more articles ==		== more articles ==

Tantek: /* Well, what about hAtom? / Update 2013, no more entry- in h-entry.

2013-07-01T23:15:24Z

Well, what about hAtom?: Update 2013, no more entry-* in h-entry.

← Older revision		Revision as of 23:15, 1 July 2013
Line 85:		Line 85:

	You can't pair "entry-" with some arbitrary other word (even existing microformats property name) and have it work or even mean anything. Thus "entry-" is not a stand-alone prefix, and has no defined meaning or function on its own, contrary to anything even resembling a namespace.		You can't pair "entry-" with some arbitrary other word (even existing microformats property name) and have it work or even mean anything. Thus "entry-" is not a stand-alone prefix, and has no defined meaning or function on its own, contrary to anything even resembling a namespace.

			Update 2013:

			We've fixed this fully in [[microformats2]] [[h-entry]]:

			* "name" replaces entry-title
			* "content" replaces entry-content
			* "summary" replaces entry-summary

			Once again, we found that even prefixing for this specific case was unnecessary in practice.

	== more articles ==		== more articles ==

Tantek: /* namespaces unnecessary in practice */ provide a specific list, and cite email source

2012-05-16T23:34:28Z

namespaces unnecessary in practice: provide a specific list, and cite email source

← Older revision		Revision as of 23:34, 16 May 2012
Line 57:		Line 57:

	== namespaces unnecessary in practice ==		== namespaces unnecessary in practice ==
	In practical use cases for marking up visible data, namespaces, bound prefixes etc. have never been necessary.		In practical use cases for marking up visible data (and others), namespaces, bound prefixes etc. have never been necessary. E.g.[http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1584.html]:
			* rel="" values in HTML, e.g. [[rel-me]]. More: [[rel-values]] define them for [[HTML5]]
			* element names in HTML, e.g. <code><p></code>
			* MIME type names, e.g. "image/png"
			* scheme names, e.g. "http", "https"

	== namespaces cause dogmatic noise ==		== namespaces cause dogmatic noise ==

Tantek: added namespaces unnecessary in practice, and namespaces cause dogmatic noise

2009-11-26T23:25:49Z

added namespaces unnecessary in practice, and namespaces cause dogmatic noise

← Older revision		Revision as of 23:25, 26 November 2009
Line 55:		Line 55:

	Basically, adding bound prefixes to any language or format design adds fragility, difficulty of use, difficulty of implementation, and in general must be avoided.		Basically, adding bound prefixes to any language or format design adds fragility, difficulty of use, difficulty of implementation, and in general must be avoided.

			== namespaces unnecessary in practice ==
			In practical use cases for marking up visible data, namespaces, bound prefixes etc. have never been necessary.

			== namespaces cause dogmatic noise ==
			It appears the desire for abstract bound (or literal) prefix namespaces causes a small strongly outspoken minority, especially on email lists, to frequently post long messages in apparent attempted support for namespaces as a concept, technology, add-on, feature etc., without bases in real world use cases. They often state namespaces themselves as the real world use case, which is of course, tautological. For example, see archives of public-html on w3.org in 2009.

			It's not clear what about namespaces incites this primarily religious/dogmatic/tautological behavior among some individuals, but the behavior itself is quite unproductive (noise in community communications channels), and thus undesirable and [[mailing-lists#Bad_topics_for_discussion\|explicitly discouraged]].

	== non-namespaced techniques have been succeeding ==		== non-namespaced techniques have been succeeding ==

Tantek: /* see also */ added more articles, with more specific namespaces critiques by Henri

2009-08-25T22:23:26Z

see also: added more articles, with more specific namespaces critiques by Henri

← Older revision		Revision as of 22:23, 25 August 2009
Line 73:		Line 73:

	You can't pair "entry-" with some arbitrary other word (even existing microformats property name) and have it work or even mean anything. Thus "entry-" is not a stand-alone prefix, and has no defined meaning or function on its own, contrary to anything even resembling a namespace.		You can't pair "entry-" with some arbitrary other word (even existing microformats property name) and have it work or even mean anything. Thus "entry-" is not a stand-alone prefix, and has no defined meaning or function on its own, contrary to anything even resembling a namespace.

			== more articles ==
			Here are some more articles and posts that discuss additional practical problems with namespaces, with specific examples
			* <span class="hentry"><span class="published">2009-03-06</span> <span class="entry-summary">public-html list: <cite class="entry-title">[http://lists.w3.org/Archives/Public/public-html/2009Mar/0163.html Re: @rel syntax in RDFa (relevant to ISSUE-60 discussion), was: Using XMLNS in link/@rel]</cite> by <span class="author vcard""><span class="fn">Henri Sivonen</span></span> explains more problems with xmlns, and of communities burdening each other.</span></span> Some quotes: <blockquote><p>I think it's a problem for collaboration where the subcommunities interact at the W3C if one subcommunity wants things and another bears the cost. </p><p> There a previous example in the form of inflicting permanent complexity (i.e. cost) onto an adjacent subcommunity: Namespaces in XML wasn't something that the SGML documentation community (turned into XML community) needed. Instead, Namespace in XML were a requirement posed by the Semantic Web community's RDF/XML. This requirement permanently complicated the processing model for the SGML community turned into XML community: http://www.flightlab.com/~joe/sgml/sanity.txt</p></blockquote>
			* <span class="hentry"><span class="published">2008-08-24</span> <span class="entry-summary"><cite class="entry-title"><nowiki>[whatwg]</nowiki> [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-August/015941.html RDFa]</cite> by <span class="author vcard"><span class="fn">Henri Sivonen</span></span> explains problems with: xmlns attributes, DOM consistency, cruftiness in language design, ccREL, indirection via prefixes</span></span>. Some choice quotes: <blockquote><p>Metadata about a file travels best inside the file, and common Web formats have native facilities on the key-value level.</p></blockquote> ... <blockquote><p>The most common case of CC metadata fits the simple key-value case, and licensing is already too hard. Addressing the more complex cases by making the common case complex seems like a bad idea to me.</p></blockquote> see related [[licensing-brainstorming#ccREL_issues\|ccREL issues]]. <blockquote><p>I think URIs (directly or through indirection) are more clumsy as identifiers than short names. Since RDF vocabularies use URIs as identifiers, I find creating more microformats (even if they need more one-off speccing) a more appealing way forward from the language usage point of view than importing RDF vocabularies in a generically mappable way. (I can't see how generic mapping can be had without using URIs as identifiers.)</p></blockquote> ... <blockquote><p>I think indirection via prefixes is bad, because experience with Namespaces in XML shows that it confused people a lot. Both full URIs and short prefixed names where the fixed prefix doesn't expand into anything are better.</p></blockquote> ... <blockquote><p>we should refuse a mechanism that can reasonably be expected to have a relatively high failure probability. As the toolchain becomes longer, the probability of failure increases, since it takes only one tool in the chain to fail for the whole chain to fail.</p></blockquote>
			* <span class="hentry"><span class="published">2002-04-05</span> <span class="entry-summary"><nowiki>[xml-dev]</nowiki> <cite class="entry-title">[http://www.flightlab.com/~joe/sgml/sanity.txt A plea for Sanity]</cite> by <span class="author vcard"><span class="fn">Joe English</span></span> </span> </span>


	== see also ==		== see also ==

Tantek: /* Well, what about hAtom? */ the blog post / fn remark seems to confuse the point (not sure what it means?) so removing it, expanded more on point about "entry-" just being part of the name of

2009-08-06T21:39:30Z

Well, what about hAtom?: the blog post / fn remark seems to confuse the point (not sure what it means?) so removing it, expanded more on point about "entry-" just being part of the name of

← Older revision		Revision as of 21:39, 6 August 2009
Line 68:		Line 68:
	It doesn't use namespaces because "entry-" just part of the name, rather than a prefix that is associated with a URL.		It doesn't use namespaces because "entry-" just part of the name, rather than a prefix that is associated with a URL.

	In this case the prefix "entry-" means nothing more than "entry-". Each of those specific ~~full~~ terms ''is so specific to the problem domain'' that we invented names specifically for them. For example, "entry-title" isn't any old title, it's specifically the Atom concept of a title. ~~You could imagine a blog post semantically marked up where a~~ "fn" ~~is around~~ the entry-~~title~~ with some ~~more information~~ ("~~David Janes says...~~").		In this case the prefix "entry-" means nothing more than "entry-". Each of those three specific terms ''is so specific to the problem domain'' that we invented names specifically for them. For example, "entry-title" isn't any old title, it's specifically the Atom concept of a title.

			Each of those three terms is defined on its own, fully spelled out with the "entry-" part of their name, in the [[hAtom]] spec.

			You can't pair "entry-" with some arbitrary other word (even existing microformats property name) and have it work or even mean anything. Thus "entry-" is not a stand-alone prefix, and has no defined meaning or function on its own, contrary to anything even resembling a namespace.

	== see also ==		== see also ==

Tantek: entry title auto-toc

2009-08-05T23:20:14Z

entry title auto-toc

← Older revision		Revision as of 23:20, 5 August 2009
Line 1:		Line 1:
	<h1> namespaces considered harmful </h1>		<entry-title> namespaces considered harmful </entry-title>
	~~{{TOC-right}}~~

	In particular namespaces for '''content''' are considered harmful (e.g. XML namespaces, QNames in attributes etc.). Namespaces for code is outside the bounds of the topic of this page.		In particular namespaces for '''content''' are considered harmful (e.g. XML namespaces, QNames in attributes etc.). Namespaces for code is outside the bounds of the topic of this page.

Tantek: add Hixie's post on Why bound prefixes are an anti-pattern in language design

2009-08-05T23:19:24Z

add Hixie's post on Why bound prefixes are an anti-pattern in language design

← Older revision		Revision as of 23:19, 5 August 2009
Line 43:		Line 43:
	=== example of fundamental software engineering error ===		=== example of fundamental software engineering error ===
	As [http://krijnhoetmer.nl/irc-logs/whatwg/20080801#l-160 othermaciej observed in IRC 2008-08-01]: <blockquote><p>Namespaces are an example of the Fundamental Software Engineering Error, which is that something too terrible to actually use can be fixed by adding a level of indirection. Sometimes that is true but software engineers try to do it even when it clearly is not.</p></blockquote>		As [http://krijnhoetmer.nl/irc-logs/whatwg/20080801#l-160 othermaciej observed in IRC 2008-08-01]: <blockquote><p>Namespaces are an example of the Fundamental Software Engineering Error, which is that something too terrible to actually use can be fixed by adding a level of indirection. Sometimes that is true but software engineers try to do it even when it clearly is not.</p></blockquote>

			== bound prefixes are an anti-pattern ==
			Ian Hickson describes numerous problems with bound prefixes in his post:
			* [http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Aug/0035.html Why bound prefixes are an anti-pattern in language design]

			Some excerpted points:
			* '''Copy-and-paste brittleness.''' Copy-and-paste of the source becomes very brittle when two separate parts of a document are needed to make sense of the content.
			* '''Hard for authors.''' Prefixes are notoriously hard for authors to understand.
			* '''More indirection adds difficulty''' Fundamentally, prefixes are an indirection model. Indirection models are very, very hard for people to understand.
			* '''Hard for implementors.''' Prefixes are notoriously hard for implementors to get right.
			* '''Hard for dynamic content situations.''' Prefixes in dynamically changing content are even worse because they require than an observing software agent not only track the value that they are concerned about, but also all possible ways for the value's prefixes to change meaning.

			Basically, adding bound prefixes to any language or format design adds fragility, difficulty of use, difficulty of implementation, and in general must be avoided.

	== non-namespaced techniques have been succeeding ==		== non-namespaced techniques have been succeeding ==
Line 54:		Line 67:
	* entry-summary		* entry-summary

	It just ~~looks like it uses an~~ "~~emulates namespace~~" - ~~the definition~~ of those ~~three items~~ ''is so specific to the problem domain'' that we invented names specifically for ~~that~~. For example, "entry-title" isn't any old title, it's specifically the Atom concept of a title. You could imagine a blog post semantically marked up where a "fn" is around the entry-title with some more information ("David Janes says...").		It doesn't use namespaces because "entry-" just part of the name, rather than a prefix that is associated with a URL.

			In this case the prefix "entry-" means nothing more than "entry-". Each of those specific full terms ''is so specific to the problem domain'' that we invented names specifically for them. For example, "entry-title" isn't any old title, it's specifically the Atom concept of a title. You could imagine a blog post semantically marked up where a "fn" is around the entry-title with some more information ("David Janes says...").

	== see also ==		== see also ==

Tantek: provided evidence/citation/example for literal string matching a common namespace prefix usage

2009-04-06T20:35:44Z

provided evidence/citation/example for literal string matching a common namespace prefix usage

← Older revision		Revision as of 20:35, 6 April 2009
Line 10:		Line 10:

	It's been tried by numerous groups, before microformats, and after. It's even been tried in the context of RSS and RDF, and in practice people write		It's been tried by numerous groups, before microformats, and after. It's even been tried in the context of RSS and RDF, and in practice people write
	scrapers that look for namespace prefixes as if they are part of the element name, not as mere shorthands for namespace URIs.		scrapers that look for namespace prefixes as if they are part of the element name, or perform literal string matches on common namespace prefix uses (e.g. [http://google.com/codesearch/p?hl=en#J7osgojbryc/src/java/org/web3d/x3d/jaxp/X3DSAVAdapter.java&q=X3DSAVAdapter&l=854 1]), not as mere shorthands for namespace URIs.

	If you want to carry on a theoretical discussion of namespaces, please do so elsewhere, for in practice, discussing them is a waste of time, and		If you want to carry on a theoretical discussion of namespaces, please do so elsewhere, for in practice, discussing them is a waste of time, and