W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > September 2007

Re: Namespace Fixup Proposal

From: Norman Walsh <ndw@nwalsh.com>
Date: Thu, 06 Sep 2007 08:11:17 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2veaouh7e.fsf@nwalsh.com>
/ ht@inf.ed.ac.uk (Henry S. Thompson) was heard to say:
| Norman Walsh writes:
|
|> / Alex Milowski <alex@milowski.org> was heard to say:
|> | There are some steps, like p:insert and p:replace, where fixup isn't
|> | the correct thing.  Those steps should preserve the in-scope namespaces
|> | so that any content that relies up it still works.
|>
|> How can fixup be the wrong thing? In fact, how does fixup even arise
|> in p:insert or p:replace; they exchange elements and, assuming that
|> the input document has the right namespace bindings, the output must,
|> mustn't it?
|
| Yes, but it still won't necessarily serialise without work, and it's
| possible that serialising will introduce failure to round-trip.
| Suppose the matrix has an ns-attribute for the default namespace, but
| the included bit consists entirely of no-namespace elts.  The
| serialised result will be borked.  To detect this, you have to look at
| every node in the inserted tree.

I suppose the default namespace *is* a special case. But I don't think
that's a problem.

Here's a document:

  <rootelem xmlns="rootns">
    <div xmlns="xhtml">
      <target/>
    </div>
  </rootelem>

Suppose I want to replace target with some subtree. When do I ever have
to look at the subtree's descendants?

To insert

  <x:otherroot xmlns:x="xxxns">
    <nons/>
  </x:otherroot>

I simply make sure that if there's a default namespace where 'target'
appears, I undeclare it. Everything else "just works". No?

|> Allowing un-fixed-up markup to flow between steps lets it get deeply
|> burried in documents through operations that wouldn't normally cause
|> fixup to be necessary.
|
| I don't understand.

My point is just that there are a few steps that allow namespaces to
get out of wack. If we don't mandate that namespaces are fixed up *on
those steps*, then *every* step can produce documents that have broken
namespaces. That just seems awful.

|> On a separate, but related, topic, I'm confused about how the SAX
|> argument plays out. Why is it hard to do this fixup with SAX? When do
|> you ever have to buffer more than one start element event?
|
| SAX filters just pass along what you give them.  If we require NS fixup
| between steps, everyone using a SAX substrate will have to put an NS
| fixup filter _every_ pair of steps, won't they?

I don't think so. It just means that, *in steps where namespaces can
get broken*, *the step* will have to make sure that it doesn't output
broken elements. But it'll never have to buffer more than one start
tag to do that, I think.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Internet connection, $19.95 a month.
http://nwalsh.com/            | Computer, $799.95. Modem, $149.95.
                              | Telephone line, $24.95 a month.
                              | Software, free. USENET transmission,
                              | hundreds if not thousands of dollars.
                              | Thinking before posting, priceless.
                              | Somethings in life you can't buy. For
                              | everything else, there's
                              | MasterCard.--Graham Reed, in the Scary
                              | Devil Monastery

Received on Thursday, 6 September 2007 12:11:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:54 GMT