Closed Bug 454831 Opened 13 years ago Closed 13 years ago

Create a policy for hosting content at namespace URIs

Categories

(mozilla.org :: Governance, task)

PowerPC
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: davidwboswell, Assigned: zak)

References

Details

I've been looking through the open www.mozilla.org bugs and there are several requests to create pages on the site to host a page for various namespace URIs.  For instance:

XBL bug 334634
microsummaries bug 354964
MozSearch bug 452351
XForms bug 419708

From reading the bugs it seems that having namespace URIs resolve to a real page isn't necessary, but it is desirable.  It sounds like not having a page causes confusion and setting up a redirect isn't desirable because people aren't sure what URI to use for the namespace.  The various bugs have more description about the issues.

There's a page up at the XUL namespace URI so this is something we've done before.  Should we just go ahead and add pages for these other namespace URIs or is this something that needs more discussion?  This is not an area I'm familiar with so I wanted some guidance.
This sounds like a good idea to me, though we probably should have some guideline for any namespaces created in the future, so we get them into a common style, i.e. directory. The already existing ones probably need to stay what they are anyway - including the XUL one that still makes a great joke for those who understand it (including the actual content on the page!)
The only possible objection is that there could be software which fetches the URIs. I suggest you talk to someone who knows about this stuff such as dbaron and if he says it's OK, go ahead and do it.

Gerv
There is no generic software that fetches arbitrary namespace URIs - RDF-related namespaces quite often serve RDF, but no specification requires them to do so, nor have they agreed on what RDF and how it should be serialized and whether it should be embedded in another document and how and...

The "only possible objection" is the desire to use each and every instance of someone encountering their first namespace URI which does not serve a namespace document (something they won't hit until they leave W3C specs, since anything on the W3C recommendation track has been required to return a document from any namespace URI it defines, since ten months after Namespaces was first published) as a teachable moment, a chance to explain to the hundredth or thousandth person that namespace URIs are opaque strings and even if they look like http URIs, they are not required to return anything.

I would cc the people that I know are in that camp, but curiously enough, despite their love for such teachable moments, they seem to uncc themselves from bugs concerning namespace documents with great vigor, frequency, and rapidity.

We could continue this desultory discussion for another three years or so (or, knowing us as I do, six or nine or twelve years), or someone with access and a web tree checked out could follow the W3C's example as seen in the SVG and XLink specs, and for the namespaces where someone has cared enough to file a bug just bloody well check in

[[
This is an XML namespace defined in the <a href="link-to-spec">Name of spec</a>.

For more information about Thing, please refer to <a href="link-to-devmo">The Devmo Introduction to Thing</a>.
]]]

adjusting as need be for things which lack a separate spec and intro, and we could be done with all this.

(Mildly amusing: http://www.w3.org/1999/10/nsuri#about (the "much lengthy discussion of the philosophy behind this [...] let us all get down to the rest of our business" part).)
David: I suggest you or one of your team just go ahead and do this.

Gerv
Sounds good.  The owners of the various projects can decide if they want to do this or not, but knowing there are no governance objections to this is helpful.  Closing as fixed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
No longer blocks: 519042
You need to log in before you can comment on or make changes to this bug.