Next Round

[james anderson]

there are some of us who believe that this is where such processing well belongs.

my misgivings about the spec (expressed at length in the past) have little to
with the model required to implement it - which is, as i've recounted in the
past, quite simple. it has to do with the barouqness and the incompleteness of
the encoding.

Tyler Baker wrote:
> 
> Bill la Forge wrote:
> 
> > Namespace Support
> > --------------------
> >
> > Why not support Namespaces through a filter? Why put everything into a monilithic parser?
> ...  The
> way things are currently defined, you pretty much have to do namespaces at the parser level.
>

as well should be done.

 
> ...  Does anyone else here feel that "Namespaces in XML"
> is being shoved down their throat?

Yes, but not for the reasons you note. I regret having to implement a spec
which is incomplete. I also note that many of the complaints about it are
analogous to complaining that it is more complicated to code for a domain
where numbers are represented in packed decimal form, binary integer, and
ascii base x, while simultaneously refusing to recognizes that the role of a
parser is to transform into a uniform, easily manipulated representation.

i recognize that both the multi gigabyte filtering applications and the 64K
smart-card applications are in a different ballbark, and might not agree to
these sentiments, but by the same token, I see no reason that a well
structured sdk have to play by those extreme rules.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)