XFastParser - next steps ...

[Michael Meeks]

Hi Mohammed,

	Let me CC the dev list on the fag-end of this conversation; hopefully
it will get more interesting over time =)

On Mon, 2016-06-27 at 22:01 +0530, Mohammed Abdul Azeem wrote:
> I'm looking into the code paths which misuses defined namespaces
> without resolving them. I will make test cases to cover them. 

	Ah - right =)

> Sure we can do this, but it would only account for element's namespace
> and not attributes namespaces. Also some of the implementations of
> XDocumentHandler expects namespace declaration( looking for "xmlns" )
> and tries to resolve them, and I think this approach wouldn't cover
> all the namespace declaration.

	Ah ! fair enough - then (I guess) we need to implement a new
XFastNamespaceHandler which we can register with a setNamespaceHandler()
call on XFastParser - and which can be NULL for all the interesting
cases where we need to be truly fast =)

	Then (I guess) we could pass namespace prefixed names through for the
unknown attributes so eg. "office:foo" - and still have the information
we need to properly resolve them.

	Failing that (I guess) - we could as you've done push xmlns: statements
through in attributes - it would best match the css::xml::Attribute
approach that expat_wrap used in the past - and would simplify things
for us.

	In this case - I'd want to see:

	a) comprehensive test cases, with assertions for all
	   code-paths.
	b) never creating these or slowing code-paths where
	   the XFastParser is being used and tokenizing correctly
	   and really needs to be fast.

	I fear that b) is not met by the previous patch.

	Thoughts ? =)

	ATB,

		Michael.

-- 
michael.meeks at collabora.com <><, GM Collabora Productivity
 Skype: mmeeks, Google Hangout: mejmeeks at gmail.com
 (M) +44 7795 666 147 - timezone usually UK / Europe