On 04.08.01 at 11:11, Jason E. Stewart <[EMAIL PROTECTED]> wrote:
>Here's the email that talks about xerces-j support for XML Catalog:
>
>http://marc.theaimsgroup.com/?l=xerces-j-dev&m=98272746310789&w=2
Ok, I was looking at
<URL:http://lists.xml.org/archives/xml-dev/200004/msg00127.html>.
>Here's a very nice article by Norm Walsh about the whole issue, with
>pointers to the Java classes:
>
>http://www.arbortext.com/html/issue%5Fthree.html
Ah, thanks!
>So, as far as I can tell, the answer to #2 is 'No', Xerces-c doesn't
>have support for XML Catalog, so we'll have to add it to Xerces.pm
Ok, I'm building something as XML::Xerces::EM -- for lack of a better name
-- but renaming it or munging the code in other ways shouldn't be a problem
once something is actually implemented.
>I'm assuming that the XML Catalog draft you're looking at is:
>
>http://www.oasis-open.org/committees/entity/spec-2001-08-02.html
Yeah. I was looking things up on my Linux box and sending email from my
Mac; I'd meant to include references for everything, but lazyness got the
better of me. :-)
>No, DOM preserves order. The tree structure that it builds in memory,
>exactly models the underlying structure of the document. So you can
>traverse the DOM tree using a tree walker and get the exact same thing
>you would using SAX.
>
>The importance question I had was whether the DOM accessor methods,
>like getElementsByTagName() preserved order, and given a simple test
>it appears that they do.
Oh, ok. I was under the impression that DOM did not preserve order and that
if current accessors did it was incidental to the implementation. If DOM is
supposed to preserve order then I guess the accessors are deliberately
written do do so too. No?
>There is another important issue, though. I suspected that they needed
>to be handled in order, but to get something out with 1.5.4 I just
>dumped each element collection into a hash table (one for PUBLIC ids,
>and another for SYSTEM ids). This might not work. I'll have to think
>about it once I read the spec.
Well, I was going to go for a lazy recursive decent parser, but then they
went and changed the semantics overnight (literally; from the Aug. 1st
draft to the Aug. 2nd draft! ;D) so instead of first-match it now has
longest-match semantics. I suspect these in combination makes a full parse
necessary.
OTOH, I'm not too worried if the first cut isn't 100% up to the spec. It's
still a draft and they need thre interopoerable implementations from OASIS
members before it progresses to final version. There's time to fine tune it
-- or unbreak it :-) -- afterwards.
>I'm glad that you're working on this Terje. When we add support for this,
>Xerces.pm is likely to be the only Perl module to have support for it.
"...but no pressure, ok?" :-)
As should be obvious I'm in somewhat over my head. I'm betting on solving
this by a "Swim or Drown" philosophy. :-)
>I'm not much of a SAX person, but as far as I can tell, no. The only
>issue is that SAX1 might be better supported by Xerces.pm. I can't say
>that for certain, but I just don't have very many tests in place for
>SAX2.
Ok, if I can use DOM I see no particular reason to go with SAX here.
Thanks for the help, jas!
--
>For all I know they probably have standards on
>which direction to put the thread on a bolt.
That would be ISO 261:1973. -- John Cowan <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
