[
Lists Home |
Date Index |
Thread Index
]
Michael Kay wrote:
>
> Michael Kay:
> > And I have yet to see a
> > > proposal that cleans up the namespace model without
> > breaking applications that work today according to the current specs.
> >
> James Anderson:
>
> > To the extent that an application expects a prefix-namespace binding
> > which was apparent in the dynamic context of a given document's parser
> > to have indefinite extent, the application is already broken.
> >
> Sorry, but we're on a different wavelength.
Let's see if we can tune into the same wavelength?
> I don't see how you can describe
> an application that uses facilities defined in the current W3C
> specifications (facilities that were put there deliberately and that are
> implemented uninformly in a dozen products) and that uses these facilities
> as they were designed to be used, as "broken".
Can a DOM which cannot support operations like
(let ((document
(parse-document
"<e1><e2 p1:a1='v1' xmlns:p1='nsn1'/><e3 p1:a1='v2' xmlns:p1='nsn2'/></e1>")))
(push (first (attributes (first (children (root document)))))
(attributes (second (children (root document)))))
(write-node document *trace-output* :pretty t))
==>
<?xml version='1.0' encoding='UTF-8' standalone='yes' ?>
<!DOCTYPE e1 [
<!-- no root element definition present -->
]>
<e1>
<e2 xmlns:p1='nsn1' p1:a1='v1' />
<e3 xmlns:p1='nsn2' nsp-1:a1='v1' p1:a1='v2' xmlns:nsp-1='nsn1' />
</e1>
#<DOC-NODE <no uri> #x9A3B976>
be said to work for documents which are namespace-aware?
Can implementations built on such a DOM be said to work for documents
which are namespace-aware?
>
> We can regret the fact that it was specified it that way (that's what I mean
> by hindsight), but we can't pretend that it wasn't.
>
Which doesn't mean one can't fix it.
...
|
