- 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