The Journey

• Use Cases for Namespaces
• Some Problems
• A Proposal
• Discussion.

Use Cases for Namespaces

• Copy and Paste
• Vocabulary Mingling
• Embedding
• Behavioural Needs.

Use Case: Copy and Paste

• Take a fragment of a document and paste it elsewhere, using a generic text editor, and not have confusion about names from different vocabularies;
• Consequence: need to mark the pasted elements, or at least the highest element of each pasted tree.
• [note] contrast with the case where you want to paste markup where the element names are the same, and you want the pasted elements to be in the new namespace! Both use cases are valid.

Use Case: Vocabulary Mingling

• Define small vocabularies, e.g. xlink, and use them in other vocabularies, e.g. SVG; this leads for example to attributes in a different namespace than their parent (xlink:href, xsi:nilled).

Use Case: Embedding

• Put one document inside another, e.g. SVG inside XSL-FO;
• Different from copy and paste only in that embedding is at certain well-defined points.

Use Case: Behavioural Needs

• Software that needs to know how to process XML can do so based on namespaces; it used to use public identifiers, but those were not Web-happy.

People: For whom?

• Authors using text editors (hence prefixes)
• [note: the prefix syntax is easier for people to type and edit by hand than explicit URIs everywhere]
• Machine-generated XML
• Software that needs to trigger behaviour
• RDF, identifying naming authority

What do namespaces do?

• Disambiguate elements and attributes
• Distributed extensibility in a way that DTDs do not.
• [note: programmers tend to expect that introducing a namespace in a document means that a pre-defined list of names immediately becomes known to the XML processor, which can then validate on this basis. This is not at all how XML namespaces work.]

Problems, real and imaginary

[note: At this point I read a quote from a 19th century book on steam engines (then cutting-edge technology). The extract described the difficulty early railway engineers had designing solutions to the the "problem" that smooth steel wheels couldn't possibly grip a smoth steel rail well enough to propel a train forwards. The first railways used rack-and-pinion, or even leather tubes filled with pressurised air, but, ultimately, it turned out that a heavy railway engine did in fact have enough friction, and wasn't a show-stopping problem.

Picture from fromoldbooks.org.

Namespace Deficiencies 1

• Prefixes led to qnames in content
• Don't solve the copy/paste in text editor use case
• XPath /html/body//svg can't work
• Considerable user confusion about namespaces

Namespace Deficiencies 2

• A typo in a namespace URI causes sad mysteries
• No standard way to discover schemas
• You can't extend other people's namespaces
• Notations and entities not scoped
• Too much syntax for HTML 5 people.

The Rescue: Goals

• Unobtrusive
• Robust to small errors
• You can make mashups
• Web-enabled for the now.

The Rescue

Is it too late?

[note: showed a video of an old silent film with a maiden tied to the tracks, and an oncoming train]

Some proposals

• Fixed attributes in DTDs
• Java-style names
• Namespace search path
• Namespace Files
• Imaginary Namespaces

Social or Technical?

• Problem: people could get hurt by a fast-moving train
• Solution 1: a man walks in front of each train holding a red flag to warn people to get out of the way
• Solution 2: a fence with a Keep Out sign.

Fixed attributes in DTDs

• Does let users extend namespaces
• Sad Mysteries are discovered early
• Doesn't scale well (5000 requests per second)
• Web browsers don't fetch DTDs

Java-style names

• ch.cern.html.p (Tim Bray, Micah)
• Really breaks badly when the namespace changes
• Efficient Processing needed
• Does solve one copy/paste use case (preserve)
• Makes copy/paste between vocabularies impossible
• Does not work with CSS or JavaScript without changing the browsers

Name search path

• <student xmlns="html people foaf"> (Ian Hickson)
• Incompatible with everything.
• Unobtrusive, best for the author
• Web compatible

Pragmatic namespaces

• Similar to Java proposal, but also hard-wires knowledge of some domains.

Namespace Files 1

• <student ns="student.nsd">
• student.nsd
• XSLT or XQuery (say) can read the nsd file and add explicit namespace bindings to documents, e.g. for validation

Namespace files 2

• copy/paste handled if context is compatible
• unobtrusive
• compatible
• extensible
• can be mixed with existing syntax.

Imaginary Namespaces

• allow an application to have a default namespace definition file. A document can override this.
• The default nsd file for a Web browser has (say) a 12-month expiry; new version shipped by browser vendor as an update. Hence, can add new namespaces.
• Updates for HTML are dated, so you can look at the definition for a given date.

Questions and Ending

• About W3C
• About XML or other things we're doing in this area
• If not here, I'm liam@w3.org
• www.w3.org/XML/
• Especial thanks to Micah for reviewing this!