XOM API for Processing XML with Java

[Peter Murray-Rust <pm286 AT cam.ac.uk>]

Thanks Mike,


On Sun, Oct 6, 2013 at 10:28 AM, Michael Kay <mike AT saxonica.com> wrote:

> >
> > Would there be any difference between attribute content and element
> > content?
> >
>
> I think it's more likely that parser designers have thought carefully
> about how to handle long text nodes than about how to handle very long
> attributes.
>
> I'd agree. In which case it may be worth experimenting. If I do, I'll let
this list know. The problem is that it won't be standard SVG and I'll
probably have to have some sort of hack such as creatiing a non-SVG
namespaace for an element child in svg:image content and a postprocessing
hack.

Can I assume that:

String imageData = "really huge string with imageData";
element.addAttribute(new Attribute("href", imageData, XLINK_NS));

won't suffer masssive performance problems?



> For example, the SAX interface allows character data to be broken up into
> chunks as the parser sees fit, and to be passed as a reference into a
> char[] array, whereas attribute values have to be passed as a single
> String. It wouldn't surprise me if the case of attribute values crossing
> buffer boundaries is considered sufficiently rare that a simple string
> concatenation is used, which implies quadratic performance as the attribute
> length increases. That's pure conjecture, but it seems consistent with what
> you are seeing.
>
> Agreed - it looks like a quadratic performance problem.

It suggests an infelicity in the SVG design (perhaps one of those things
that only bites you after release). I can work round it for my own case.



-- 
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069