• From: Marcus Reichardt <u123724@g...>
• To: Rick Jelliffe <rjelliffe@a...>
• Date: Sat, 24 Jul 2021 10:26:09 +0200

The deeper critique of namespaces, as brought up by Arjun et al here,
is more nuanced, and follows from a somewhat broader SGML-ish
perspective on markup.

In traditional SGML, a DTD grammar is obligatory, and isn't as
disconnected as eg an XML Schema is from an XML instance, but rather
something the author of a document has control over as opposed to
something designed by a committee of experts. Element declarations are
also needed for parsing rather than mere "validating" a document; for
example, an HTML parsers needs to know that an <img> element must have
no end-element tag. Likewise, short references are means to
drastically customize the interpretation of text content, with
applications ranging from automatically interpreting end-of-line
characters as end-element tags, to translating CSV, JSON, and Wiki
syntaxes into markup, with the additional help of content-model driven
tag inference, a powerful concept that didn't make it into XML. The
shortref idea made the rounds as "invisible markup" in the XML world a
couple years ago.

Now in SGML, giving you so much more control over how your document
looks like and in general focusing on authoring text with a plain-text
editor as opposed to WYSIWYG, there's no point in an additional device
that plays games with names, especially since the hard parts of
vocabulary integration - the semantics - aren't covered at all. In the
greater SGML context, HyTime introduced "architectural forms", a
mechanism that could rename elements and attributes (from your own to
a committee-designed rendering vocabulary, for instance) and produce
"views" of your markup.

(Now SGML also has LPDs, a type of declaration set available in
addition to DTDs, to basically do the same thing, and that can be even
pipelined OOTB; it's unclear to me why archforms didn't extend LPDs
but rather invented it's own IS10744 PI for basically the same thing
without adding power where it was needed, such as for dealing better
with attribute mappings or filtering).

On 7/24/21, Rick Jelliffe <rjelliffe@a...> wrote:
> Marcus R brought up this blog recently:
>    https://blog.jclark.com/2010/01/xml-namespaces.html
> Here is a summary of the various POVs.
>
> *James C: * Capability is occasionally useful, but not that useful.
> prefix/namespace disutiliy outweighs utility.
>      Using URIs was not necessary and uncritically adopted.  But good for
> RDF.
>     Nesting declarations seemed reasonable at the time, but ....
>
> *Michael K:* Should be built in, not layered.     Using URIs is a
> misguided. URIs don't get dereferenced to get the schema
> etc anyway.   Unclarity about infoset status of prefixes.
>
> *E Rusty H:*  Qnames in content a mistake. (Namespace declarations apply to
> XPaths in attributes? RJ: not in Schematron
> they don't!)    Making declarations element-scoped (rather than
> document-scoped) and overrideable (especially
> default mapping) is the problem.
>
> *Mukul G:*  Being able to bind to schemas, and preventing name collusions
> is useful.
>      (But don't adopt unless clearly required.)
>
> *Tony C, Unknown, Anonymous. Ditto *   What is the alternative?  How do we
> automatically bind a document to a schema?
>
> *Orcmid: *Inability to have certainty w.r.t. schemas.
>
> *LIam Q:* HTML5 crowd also dislikes namespace syntax: the HTML 5 processor
> implies the namespace from the element name.
>   Proposal for "Unobtrusive Namespaces" and "Imaginary Namespaces"
>
> *David RRW: * CAM uses dictionary instead of namespaces. (I.e. individual
> name registration?)
>      Only place namespaces were useful was distinguishing (formatting)
> annotations not part of original content.
>
> *Ed D: * No mechanism to say when qname in content is used.  DTDs should
> have been made namespace aware.
>
> *Pierre A: *Good to integrate namespaces into XML spec.   Use of qnames in
> content difficult.
>
> *Murata-sensei:*  Namespace declarations better as PIs.  Nesting bindings a
> problem.  qnames in content (or attributes)
>    not handled uniformly.
>
> *John C:*LMNL didn't allow prefix remapping or multiple prefixes for the
> same URI.  Namespace declarations not tied to elements. Lexical scoping.
> Different rules for default namespace.
>
> *Gavin N:* Namespaces add significantly to DOM size.  Couples processing
> and semantcs unnecessarily.  Namespaces fight extensibility.
>
> *Bent R: *Namespaces not used enough.  Could get rid of comment and PII
> syntax by making a namespace for them instead. "Is human readability a
> benefit or an issue?" It "leads to things like attributes". "Really there
> are only elements"
>
> *Virendra:  *need out-of-the-box approach (i.e. a different over-web
> mechanism not just a different syntax?)
>
> To which I add:
>
> *Rick: *Setting default namespaces and nested or local declarations and
> redeclarations work against "manifest markup" where you only need to look
> at the tag (and perhaps a header) to know what is going on. I appreciate
> that it was a useful mechanism for, e.g. pulling in HTML documents into
> XHTML without having to prefix every element name in a tag or mess up CSS
> stylesheets; however perhaps XHTML was really a one-off, and not so
> compelling now.
>
>
> Regards
> Rick
>

• Follow-Ups:
  • ArchForns and LPDs
    • From: Arjun Ray <arayq2@g...>
  • LPDs [Was: Summary of critiques of XML Namespace fromcomments to James Clark 2010 blog]
    • From: Tony Graham <tgraham@a...>

• References:
  • Summary of critiques of XML Namespace from comments to James Clark2010 blog
    • From: Rick Jelliffe <rjelliffe@a...>