[
Lists Home |
Date Index |
Thread Index
]
"Prefixes" are an artifactual problem. I give below a number of
examples, which demonstrate that modifications in a document model
instance are independent of the prefix=namespace-name bindings expressed
in the serialized form.
The problem devolves to answering the following question. In the form
(let ((some-prefix some-namespace-name))
(make-name (resolve-prefix-to-namespace some-prefix) some-local-part))
does (resolve-prefix-to-namespace some-prefix) reduce to a constant. If
so, the entire form can be eta-reduced to a constant. If not, that is,
if the result contains variables, then there is some implicit binding
context (for some-prefix, or for some-namespace-name, or for whatever)
and dealing with these bindings is an instance of the upward-funarg
problem. With the consequent hand-ringing about maintianing and
reconstructing (at least) prefix=naemspace-name bindings.
Question is, is there a use-case where the result is not a constant?
Ronald Bourret wrote:
>
> Paul Prescod wrote:
>
> > Remember we just had an argument about whether to design for the common
> > case or the special case? Have you ever done this in an application? I
> > haven't. Still, every XML application in the world must handle namespace
> > scoping.
>
> Every XML _parser_ must handle namespace scoping. Most applications
> don't care. For applications, I think it's an issue in only three cases
> (any others?):
>
> 1) Moving nodes around and the document uses more than one namespace
> 2) Using QNames in attribute values/PCDATA.
> 3) Serializing documents by hand.
It would be a problem, were it expected that, were the apparent binding
for a prefix modified, it would transform the namespace of those names
which it dominates in an existing instance model. An analogous situation
would arise with similar expections when nodes are moved within a
document model. The expection is, however, not readily reconciled with
any of the document model implementations or specifications.
In concrete terms,
(let ((doc-node (document-parser "<x xmlns='data:,ns-a' />")))
;; modify the value of the xmlns='data:,ns-a' namespace node
(setf (value (elem-get-property-node (root doc-node) "")) "data:,ns-unexpected")
(write-node (root doc-node) *trace-output* :encoding :us-ascii))
produces
<nsp-163:x xmlns='data:,ns-unexpected' xmlns:nsp-163='data:,ns-a' />
which is as expected, and not,
<x xmlns='data:,ns-unexpected' />
which should not be. the latter would make no more sense than expecting
that, by removing some namespace node from an element in a document
model instance, any dominated identifiers in the namespace bound by that
namespace node are suddenly in the null namespace.
...
>
> I suspect this limits the problem to people writing tools. (This is not
> to minimize the problem. It doesn't look too bad in SAX, where
> stack-based processing mimics the declarations, but it looks like a real
> pain in the DOM.)
>
> -- Ron
output from CL-XML follows. i suspect the examples are adhoc, but as i
don't think this is a problem, i've neglected a systematic analysis. if
someone has one i would be grateful for additional examples.
original. :
<doc xmlns='data:,ns-top' xmlns:a='data:,ns-a' >
<x xmlns='data:,ns-a'><z/></x>
<y xmlns='data:,ns-b'></y>
</doc>
I. original serialized. :
<doc xmlns='data:,ns-top' xmlns:a='data:,ns-a'>
<x xmlns='data:,ns-a'><z /></x>
<y xmlns='data:,ns-b' />
</doc>
II. a change of the prefix specified for a local namespace binding has
the expected effect on the serialized document, even though
#<ELEM-NODE #<UNAME {data:,ns-a}x> 2 #xA042316>.name.prefix remains = "" :
<doc xmlns='data:,ns-top' xmlns:a='data:,ns-a'>
<aChanged:x xmlns:aChanged='data:,ns-a'><aChanged:z /></aChanged:x>
<y xmlns='data:,ns-b' />
</doc>
III. moving the element does not cause the artifactual prefix to be captured.
#<ELEM-NODE #<UNAME {data:,ns-a}z> 3 #xA048DEE>.name.prefix remains = "".
the serializer uses the binding visible in the root node.
#<ELEM-NODE #<UNAME {data:,ns-b}y> 4 #xA0493EE>.namespaces = (#<NS-NODE
#<UNAME {xmlns}||> -> "data:,ns-b" #xA0492D6>). :
<doc xmlns='data:,ns-top' xmlns:a='data:,ns-a'>
<x xmlns='data:,ns-a' />
<y xmlns='data:,ns-b'><a:z /></y>
</doc>
IV. the prefixes are serialization artifacts,as show by removing the
local namespace nodes.
#<ELEM-NODE #<UNAME {data:,ns-a}x> 2 #xA0400E6>.namespaces = NIL.
#<ELEM-NODE #<UNAME {data:,ns-b}y> 4 #xA04092E>.namespaces = NIL. :
<doc xmlns='data:,ns-top' xmlns:a='data:,ns-a'>
<a:x><a:z /></a:x>
<nsp-163:y xmlns:nsp-163='data:,ns-b' />
</doc>
V. the effect of a change to the value of a namespace node is limited to
that node. it has no affect on the names within its scope.
#<ELEM-NODE #<UNAME {data:,ns-a}x> 2 #xA046AEE>.namespaces = (#<NS-NODE
#<UNAME {xmlns}||> -> "" #xA0469CE>). :
<doc xmlns='data:,ns-top' xmlns:a='data:,ns-a'>
<a:x xmlns=''><a:z /></a:x>
<y xmlns='data:,ns-b' />
</doc>
VI. even where a new node binds the original prefix to a different namespace.
#<ELEM-NODE #<UNAME {data:,ns-a}x> 2 #xA04D3DE>.namespaces = (#<NS-NODE
#<UNAME {xmlns}a> -> "" #xA04E13E> #<NS-NODE #<UNAME {xmlns}||> -> ""
#xA04D2C6>). :
<doc xmlns='data:,ns-top' xmlns:a='data:,ns-a'>
<nsp-163:x xmlns:a='' xmlns=''
xmlns:nsp-163='data:,ns-a'><nsp-163:z /></nsp-163:x>
<y xmlns='data:,ns-b' />
</doc>
VII. even where the name of the namespace is changed.
#<ELEM-NODE #<UNAME {data:,ns-nefarious!}x> 2 #xA036DE6>.namespaces =
(#<NS-NODE #<UNAME {xmlns}||> -> "data:,ns-a" #xA036D6E>). :
<doc xmlns='data:,ns-top' xmlns:a='data:,ns-nefarious!'>
<x xmlns='data:,ns-nefarious!'><z /></x>
<y xmlns='data:,ns-b' />
</doc>
|
