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]>,
> <John@Barbados "'[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]
