>is there any other work around .
I am not sure how one would "work around" a missing feature
other than to implement it. Adding an "xml-string" property
to the SAX parser is straightforward and it would simply
have to ask the DTD scanner to provide values for events.
In the scanner, you save the current offset each time that
you return from dispatching an event. If there is a call
to get the xml-string property, you just return the string
for the current parsed entity from the offset after the
last event up to the offset of the current event. If you
put a call to get the xml-string in every event that the
DTD scanner generates then you will have access to the
unparsed xml data of the entire DTD, split up on event
boundaries.
Regards,
Glenn
chandru
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
xtive.com> cc: [email protected],
Glenn Marcy/Cupertino/[EMAIL PROTECTED]
Subject: Re: DTD Reading Urgent
08/08/2001
01:10 AM
Please respond
to
xerces-j-dev
Hi ,
You mean to say i can get a solution for this with xerces2.if so what is
the release date for xerces2. i need this
desparately .is there any other work around .please suggest me.
from
chandra sekhar
Glenn Marcy wrote:
> John,
>
> Actually, it is not as bad as you make out...
>
> Here is a note that I sent to the dev list several months ago:
>
> Subject: Re: [xerces2] Note to current XNI state
>
> I have been looking into another approach. The documentation of the
> SAX2 property "http://xml.org/sax/properties/xml-string"; says:
>
> data type: java.lang.String
> description: The literal string of characters that was the source
> for the current event.
> access: read-only
>
> I have been looking at the current Xerces2 APIs and how one might add
> support for this property during DTD parsing.
>
> So, using your two examples, I get (from a DTD writer prototype):
>
> Input:
> <!ENTITY % ent "ANY">
> <!ELEMENT e %ent;>
>
> Output:
> <!ENTITY % ent "ANY">
> <!ELEMENT e %ent;>
>
> Input:
> <!ENTITY % ent " ">
> %ent;
> <!ELEMENT e ANY>
>
> Output:
> <!ENTITY % ent " ">
> %ent;
> <!ELEMENT e ANY>
>
> So this matches one of my goals of being able to take any DTD and parse
> it and be able to spit back out exactly what was parsed. In this case
> all I do is get the value of the "xml-string" property during every event
> and write it out. Now to get a feel for the event/xml-string
relationship,
> I can run the program with debugging turned on, which just adds an
> "[event-name]" to the output stream. Note that I have also added a new
> "startOfMarkupDecl" event because it made my application (the simple DTD
> writer) easier to code, but it is not "strictly" necessary. The debug
> code looks like:
>
> String propString = "http://xml.org/sax/properties/xml-string";;
>
> void printEvent(String eventName) {
> String xmlstring = (String) parser.getProperty(propString);
> if (DEBUG)
> System.out.println("[" + eventName "]" + xmlstring);
> else
> System.out.print(xmlstring);
> }
>
> So again for the same to cases:
>
> Output (with DEBUG printing added):
> [startDTD]
> [startEntity "[dtd]"]
> [startOfMarkupDecl]<!ENTITY
> [internalEntityDecl] % ent "ANY">
> [startOfMarkupDecl]
> <!ELEMENT
> [startEntity "%ent"] e %ent;
> [endEntity "%ent"]
> [elementDecl]>
> [endEntity "[dtd]"]
> [endDTD]
>
> Output (with DEBUG printing added):
> [startDTD]
> [startEntity "[dtd]"]
> [startOfMarkupDecl]<!ENTITY
> [internalEntityDecl] % ent " ">
> [startEntity "%ent"]
> %ent;
> [endEntity "%ent"]
> [startOfMarkupDecl]
> <!ELEMENT
> [elementDecl] e ANY>
> [endEntity "[dtd]"]
> [endDTD]
>
> Obviously this requires some additional "reparsing" of some of the
> simple constructs in the declarations, but it isn't too hard to keep
> straight. The nice advantage is that you do not need to add lots of
> methods to the handler APIs and you can avoid doing the work of
> creating the String until you get the getProperty call from the
> application within the handler callback. Since the parser only needs
> to be able to return the unparsed stream back as far as the last event,
> and not since the last call to getProperty, the amount of information
> that needs to be available is small. There is a little overhead on the
> edge cases at low-level reader I/O buffer boundaries, but since most
> events will occur within the same buffer as the previous event a simple
> lastXMLStringOffset variable handles the common case.
>
> Regards,
> Glenn
>
> <<<end enclosure>>>
>
> John wrote:
>
> For example, what would you like reported for this:
> <!ENTITY % someOtherFile SYSTEM "aardvark.mod">
> <!ENTITY % prefix "foo:">
> <!ENTITY % elementName "%prefix;bar">
> <!ENTITY % cmBit "a,b,c">
> <!ENTITY % fullDecl "<!ELEMENT %elementName; (%cmBit;)>" >
> %fullDecl;
> %someOtherFile;
>
> This is what I get with my DTDWriter:
>
> [startDocument]
> [startDTD]
> [startEntity "[dtd]"]
> [startOfEntityDecl]<!ENTITY
> [externalEntityDecl] % someOtherFile SYSTEM "aardvark.mod">
> [startOfEntityDecl]
> <!ENTITY
> [internalEntityDecl] % prefix "foo:">
> [startOfEntityDecl]
> <!ENTITY
> [startEntity "%prefix"] % elementName "%prefix;
> [endEntity "%prefix"]
> [internalEntityDecl]bar">
> [startOfEntityDecl]
> <!ENTITY
> [internalEntityDecl] % cmBit "a,b,c">
> [startOfEntityDecl]
> <!ENTITY
> [startEntity "%elementName"] % fullDecl "<!ELEMENT %elementName;
> [endEntity "%elementName"]
> [startEntity "%cmBit"] (%cmBit;
> [endEntity "%cmBit"]
> [internalEntityDecl])>" >
> [startEntity "%fullDecl"]
> %fullDecl;
> [startOfElementDecl]
> [elementDecl]
> [endEntity "%fullDecl"]
> [startEntity "%someOtherFile"]
> %someOtherFile;
> [endEntity "%someOtherFile"]
> [endEntity "[dtd]"]
> [endDTD]
>
> Regards,
> Glenn
>
>
> "Anderson,
> John" To:
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>,
> <[EMAIL PROTECTED] "'[email protected]'"
<[email protected]>
> oft.com> cc:
> Subject: RE: DTD Reading
Urgent
> 08/06/2001
> 01:09 PM
> Please respond
> to
> xerces-j-dev
>
>
>
> Ho ho!
>
> Found someone who wants this as well!
>
> The XML spec says that resolving is what a validating parser should do,
and
> neither SAX nor DOM APIs expose this information. I would also like to be
> able to access this information, but most people have put it in the too
> hard basket. The problem is complicated (to put it mildly) by the various
> ways in which PEs can be used, including as element names, content models
> (or parts thereof), entire declarations, includes, bits of attribute
> declarations, etc etc. Plus some local PEs to override those in the
> external DTD. I am no kind of parser expert, but I guess it would be
pretty
> difficult for a parser to not resolve this and still guarantee validity
> without doing a double pass.
>
> For example, what would you like reported for this:
>
> <!ENTITY % someOtherFile SYSTEM "aardvark.mod">
> <!ENTITY % prefix "foo:">
> <!ENTITY % elementName "%prefix;bar">
> <!ENTITY % cmBit "a,b,c">
> <!ENTITY % fullDecl "<!ELEMENT %elementName; (%cmBit;)>" >
> %fullDecl;
> %someOtherFile;
>
> Now add in a few general entities just to make it interesting, and
perhaps
> some attributes and then remember it all when you create and modify a
DOM3
> AS Model of it.
>
> As far as I know, the only way to do it would be to do some hacking in
the
> source code after determining which entities you want resolved and which
> ones you'd like passed through. Unfortunately I haven't yet had the time
to
> work out exactly how I might do this. If I do, I'll let you know.
>
> If anyone else has done it, I'd also be very grateful to know where and
how
> I should begin.
>
> John
>
> -----Original Message-----
> From: chandru [mailto:[EMAIL PROTECTED]
> Sent: 25 July 2001 05:40
> To: [EMAIL PROTECTED]
> Subject: DTD Reading Urgent
>
> Hi friends ,
> while reading the dtd using the DTDReader(using the feature
> decl-handler,of parser) .the elements content model is giving the a
> normalised definition .The model will be normalized so that all parameter
> entities are fully resolved and all whitespace is removed,and will
include
> the enclosing parentheses. how can i stop this,i want the un normalised
> definition of the element .
> e.g:
> <!ELEMENT NOE (%_NOE_;)>
> <!ENTITY % _NOE_ (Msgfun,getInfo,(Reader))>
>
> what iam expecting is:
> element name : NOE
> content Mode: (%_NOE)
>
> what the parser informs in DeclHandler is
> element name : NOE
> content Mode: (Msgfun,getInfo,(Reader))
>
> how can i regain the original declarations.i.e with out the
normalisation.
>
> Expecting your mail soon....
>
> from
> chandra sekhar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
