[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Napkin grammar

• From: Amelia A Lewis <amyzing@talsever.com>
• To: xml-dev <xml-dev@lists.xml.org>
• Date: Thu, 22 Jul 2021 23:07:38 -0400

On Thu, 22 Jul 2021 23:20:37 +0100, Pete Cordell wrote:
> If you're not interested in the new syntax being a subset of XML and 
> you still want namespaces, you'll want to consider an alternative way 
> of mapping namespace prefixes to namespaces so that the mapping is 
> available BEFORE it is required.  Currently the mapping mechanism 
> requires a fair bit of pre-fetching and caching which is sub-optimal.
> 
> Something like the following might work:
> 
> <:and http://www.whatever.com/:>
> <and:harry />

Why? That still separates :and from and:, so if you start parsing on 
the <and:harry /> line, you're busted. And why use a non-default prefix 
for an element?

<harry xmlns="http://www.whatever.com">

It is almost never *necessary* to bind a namespace to a prefix for use 
with elements. It can be verbose to repeatedly re-declare with a bad 
schema design like this:

<root>
  <othernschild xmlns="http://other.ns.example.com" />
  <othernschild xmlns="http://other.ns.example.com" />
  <othernschild xmlns="http://other.ns.example.com" />
  <othernschild xmlns="http://other.ns.example.com" />
  <!-- ... -->
</root>

This also meets the stated purpose more nearly: start parsing anywhere. 
Well, any time you've got namespace bindings (whether to a non-default 
prefix or to the default prefix), you can't start parsing anywhere; you 
have to know what the bindings are. On the other hand, however you got 
to that position in the document, you do know what the context is.

The only times that you *need* to use a non-default prefix are: (1) 
global attributes (so use xmlns:attr-prefix="xyzzy" for 
attr-prefix:attr="nothing happens") and (2) QNames in content (a 
layering violation, so do not use QNames in content in new 
specifications, and deal with the breakage for XML Schema, XPath/XSLT, 
and WSDL (and other currently-defind specifications that followed their 
lead toward using QNames in content) (wherever QNames in content 
appear, a better specification would provide namespace-name pairs, or 
if it has to use abbreviations for namespaces, then it should define 
its own syntax entirely in content, so that it passes through without 
namespace mangling by an XML processor). Note that XPath expressions 
also contain QNames in content as steps in path expressions, but that's 
just an extended case of QNames in content. For elements, the XML is 
almost always easier to read if you rebind each namespace to the 
default prefix at the point that it's needed (it keeps the declaration 
more local).

And you don't have to redefine any current specs (well, it would be 
nice to take QNames in content out of XML Schema and XPath/XSLT and 
others, but ain't gonna happen, so accept that they've got that wart 
and deal with it). It's just a best (or merely a "better") practice for 
the handling of elements in different namespaes in a single document.

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.org
  "You go on.  You just go on.  There's nothing more to it, and there's
no trick to make it easier.  You just go on."
  "What do you find on the other side?  When you go on?"
  She shrugged.  "Your life again.  What else?"
		-- Harra Csurik and Miles Vorkosigan

• Follow-Ups:
  • Re: Napkin grammar
    • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • Re: Napkin grammar
    • From: Pete Cordell <pete++xmldev@codalogic.com>

• References:
  • Napkin grammar
    • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • Re: Napkin grammar
    • From: Tim Bray <tbray@textuality.com>
  • Re: Napkin grammar
    • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • Re: Napkin grammar
    • From: Pete Cordell <pete++xmldev@codalogic.com>