- 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 UTC