You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Andy Clark <an...@apache.org> on 2001/02/01 05:40:17 UTC
Re: problem about parameter entity handling of XNI
Libor Kramolis wrote:
> Level 1: *data* oriented
> Level 2: *structure* oriented
> Level 3: *indentation* oriented
Okay, now I feel like we're getting somewhere! :)
> [example] <!ENTITY e1 '&amp;'>
> [1] - level 1 callback
> [2] - level 2 callback
> [3] - level 3 callback
>
> [2] startEntityDecl()
> [3] ignorableWhitespaces (" ")
> [2] entityName ("e1");
> [3] ignorableWhitespaces (" ")
> [2] startEntityValue ('\'')
> [2] startEntity ("#38")
> [2] characters ("&")
> [2] endEntity ("#38")
> [2] characters ("amp;")
> [2] endEntityValue ('\'')
> [2] endEntityDecl()
> [1] internalEntityDecl ("e1", "&")
Following your lead, how about the following interfaces. Don't
mind the duplicated methods -- they're included for illustrative
purposes so you know what kind of information is received at what
time.
interface XMLDTDHandler (XNI Core)
startDTD()
startEntity(String,String,String,String)
textDecl(String,String)
endEntity(String)
comment(XMLString)
processingInstruction(String,XMLString)
elementDecl(String,String)
attributeDecl(String,String,String,String[],String,XMLString)
internalEntityDecl(String,XMLString)
externalEntityDecl(String,String,String)
unparsedEntityDecl(String,String,String,String)
notationDecl(String,String,String)
endDTD()
Note that this simplifies the basic XMLDTDHandler to return only
the basic information needed to communicate the "data" declared in
the DTD.
interface XMLDTD???Handler (XNI extension)
short CONDITIONAL_INCLUDE
short CONDITIONAL_IGNORE
short SEPARATOR_CHOICE
short SEPARATOR_SEQUENCE
short OCCURS_ZERO_OR_ONE
short OCCURS_ZERO_OR_MORE
short OCCURS_ONE_OR_MORE
startConditional(short)
characters(XMLString)
endConditional()
startEntity(String,String,String,String)
textDecl(String,String)
endEntity(String)
startEntityDecl()
entityName(String) // "%e3" would be a parameter entity
startLiteral(char)
characters(XMLString)
endLiteral()
publicId(char,String) // ??? Not sure about these two
systemId(char,String)
ndata(String)
endEntityDecl()
startElementDecl()
elementName(String)
any()
empty()
startGroup()
pcdata()
element(String)
separator(short)
occurs(short)
endGroup()
endElementDecl()
startAttlistDecl()
elementName(String)
attributeName(String)
// NEEDS TO BE FILLED IN! -- Note, this part is going to
// large due to the various possibilities
endAttlistDecl()
startNotationDecl()
notationName(String)
endNotationDecl()
This level of DTD information incorporates many of the non-data
aspects of XMLDTDHandler and all of the XMLDTDContentModelHandler
interfaces, in a form changed as to allow the correct callbacks
of start/endEntity.
interface XMLDTD???Handler (XNI extension)
whitespace(char[],int,int)
ignorableWhitespace(char[],int,int) // ???
This interface reports the "indentation" information from the DTD.
NOTE: I don't believe that this is a reasonable requirement from
the DTD scanner. But I've included it anyway for the purposes of
discussion.
Let the discussion begin!
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
Re: problem about parameter entity handling of XNI
Posted by Libor Kramolis <li...@netbeans.com>.
Sorry for delay ... I was on vacation.
Comments are below.
Andy Clark wrote:
> Libor Kramolis wrote:
>
>> Level 1: *data* oriented
>> Level 2: *structure* oriented
>> Level 3: *indentation* oriented
>
>
> Okay, now I feel like we're getting somewhere! :)
>
I hope. :-))
>
>> [example] <!ENTITY e1 '&amp;'>
>> [1] - level 1 callback
>> [2] - level 2 callback
>> [3] - level 3 callback
>>
>> [2] startEntityDecl()
>> [3] ignorableWhitespaces (" ")
>> [2] entityName ("e1");
>> [3] ignorableWhitespaces (" ")
>> [2] startEntityValue ('\'')
>> [2] startEntity ("#38")
>> [2] characters ("&")
>> [2] endEntity ("#38")
>> [2] characters ("amp;")
>> [2] endEntityValue ('\'')
>> [2] endEntityDecl()
>> [1] internalEntityDecl ("e1", "&")
>
>
> Following your lead, how about the following interfaces. Don't
> mind the duplicated methods -- they're included for illustrative
> purposes so you know what kind of information is received at what
> time.
>
> interface XMLDTDHandler (XNI Core)
>
> startDTD()
>
> startEntity(String,String,String,String)
> textDecl(String,String)
> endEntity(String)
>
> comment(XMLString)
> processingInstruction(String,XMLString)
>
> elementDecl(String,String)
> attributeDecl(String,String,String,String[],String,XMLString)
>
> internalEntityDecl(String,XMLString)
> externalEntityDecl(String,String,String)
> unparsedEntityDecl(String,String,String,String)
>
> notationDecl(String,String,String)
>
> endDTD()
>
> Note that this simplifies the basic XMLDTDHandler to return only
> the basic information needed to communicate the "data" declared in
> the DTD.
Agree. This could be level *1* information.
>
> interface XMLDTD???Handler (XNI extension)
>
> short CONDITIONAL_INCLUDE
> short CONDITIONAL_IGNORE
>
> short SEPARATOR_CHOICE
> short SEPARATOR_SEQUENCE
>
> short OCCURS_ZERO_OR_ONE
> short OCCURS_ZERO_OR_MORE
> short OCCURS_ONE_OR_MORE
>
> startConditional(short)
> characters(XMLString)
> endConditional()
>
> startEntity(String,String,String,String)
> textDecl(String,String)
> endEntity(String)
>
> startEntityDecl()
> entityName(String) // "%e3" would be a parameter entity
> startLiteral(char)
> characters(XMLString)
> endLiteral()
> publicId(char,String) // ??? Not sure about these two
> systemId(char,String)
> ndata(String)
> endEntityDecl()
>
> startElementDecl()
> elementName(String)
> any()
> empty()
> startGroup()
> pcdata()
> element(String)
> separator(short)
> occurs(short)
> endGroup()
> endElementDecl()
>
> startAttlistDecl()
> elementName(String)
> attributeName(String)
> // NEEDS TO BE FILLED IN! -- Note, this part is going to
> // large due to the various possibilities
> endAttlistDecl()
>
> startNotationDecl()
> notationName(String)
> endNotationDecl()
>
> This level of DTD information incorporates many of the non-data
> aspects of XMLDTDHandler and all of the XMLDTDContentModelHandler
> interfaces, in a form changed as to allow the correct callbacks
> of start/endEntity.
Yes, this could be level *2* extension with entity reference boudaries
(start/end-Entity).
>
> interface XMLDTD???Handler (XNI extension)
>
> whitespace(char[],int,int)
> ignorableWhitespace(char[],int,int) // ???
>
> This interface reports the "indentation" information from the DTD.
Yes, and this couls be level *3* -- indentation level.
I think, this view of xml parsing make sense.
> NOTE: I don't believe that this is a reasonable requirement from
> the DTD scanner. But I've included it anyway for the purposes of
> discussion.
I think that (DTD) scanner could be more component. This was discused in
'[xerces2] XNI comments' thread and I agree with Petr's proposal.
>
> Let the discussion begin!
I am very glad, that you want to specify XNI extension, which could be
useful for xml tools usage. This extension sould support level 2 and 3 (as
you design above). Thanks.
Well, I would like to continue with discusion, so when you want (as I see)
to specify those extension interfaces, let's start specifing it.
Thanks for any answer.
Regards,
Libor
Re: problem about parameter entity handling of XNI
Posted by Libor Kramolis <li...@netbeans.com>.
Sorry for delay ... I was on vacation.
Comments are below.
Andy Clark wrote:
> Libor Kramolis wrote:
>
>> Level 1: *data* oriented
>> Level 2: *structure* oriented
>> Level 3: *indentation* oriented
>
>
> Okay, now I feel like we're getting somewhere! :)
>
I hope. :-))
>
>> [example] <!ENTITY e1 '&amp;'>
>> [1] - level 1 callback
>> [2] - level 2 callback
>> [3] - level 3 callback
>>
>> [2] startEntityDecl()
>> [3] ignorableWhitespaces (" ")
>> [2] entityName ("e1");
>> [3] ignorableWhitespaces (" ")
>> [2] startEntityValue ('\'')
>> [2] startEntity ("#38")
>> [2] characters ("&")
>> [2] endEntity ("#38")
>> [2] characters ("amp;")
>> [2] endEntityValue ('\'')
>> [2] endEntityDecl()
>> [1] internalEntityDecl ("e1", "&")
>
>
> Following your lead, how about the following interfaces. Don't
> mind the duplicated methods -- they're included for illustrative
> purposes so you know what kind of information is received at what
> time.
>
> interface XMLDTDHandler (XNI Core)
>
> startDTD()
>
> startEntity(String,String,String,String)
> textDecl(String,String)
> endEntity(String)
>
> comment(XMLString)
> processingInstruction(String,XMLString)
>
> elementDecl(String,String)
> attributeDecl(String,String,String,String[],String,XMLString)
>
> internalEntityDecl(String,XMLString)
> externalEntityDecl(String,String,String)
> unparsedEntityDecl(String,String,String,String)
>
> notationDecl(String,String,String)
>
> endDTD()
>
> Note that this simplifies the basic XMLDTDHandler to return only
> the basic information needed to communicate the "data" declared in
> the DTD.
Agree. This could be level *1* information.
>
> interface XMLDTD???Handler (XNI extension)
>
> short CONDITIONAL_INCLUDE
> short CONDITIONAL_IGNORE
>
> short SEPARATOR_CHOICE
> short SEPARATOR_SEQUENCE
>
> short OCCURS_ZERO_OR_ONE
> short OCCURS_ZERO_OR_MORE
> short OCCURS_ONE_OR_MORE
>
> startConditional(short)
> characters(XMLString)
> endConditional()
>
> startEntity(String,String,String,String)
> textDecl(String,String)
> endEntity(String)
>
> startEntityDecl()
> entityName(String) // "%e3" would be a parameter entity
> startLiteral(char)
> characters(XMLString)
> endLiteral()
> publicId(char,String) // ??? Not sure about these two
> systemId(char,String)
> ndata(String)
> endEntityDecl()
>
> startElementDecl()
> elementName(String)
> any()
> empty()
> startGroup()
> pcdata()
> element(String)
> separator(short)
> occurs(short)
> endGroup()
> endElementDecl()
>
> startAttlistDecl()
> elementName(String)
> attributeName(String)
> // NEEDS TO BE FILLED IN! -- Note, this part is going to
> // large due to the various possibilities
> endAttlistDecl()
>
> startNotationDecl()
> notationName(String)
> endNotationDecl()
>
> This level of DTD information incorporates many of the non-data
> aspects of XMLDTDHandler and all of the XMLDTDContentModelHandler
> interfaces, in a form changed as to allow the correct callbacks
> of start/endEntity.
Yes, this could be level *2* extension with entity reference boudaries
(start/end-Entity).
>
> interface XMLDTD???Handler (XNI extension)
>
> whitespace(char[],int,int)
> ignorableWhitespace(char[],int,int) // ???
>
> This interface reports the "indentation" information from the DTD.
Yes, and this couls be level *3* -- indentation level.
I think, this view of xml parsing make sense.
> NOTE: I don't believe that this is a reasonable requirement from
> the DTD scanner. But I've included it anyway for the purposes of
> discussion.
I think that (DTD) scanner could be more component. This was discused in
'[xerces2] XNI comments' thread and I agree with Petr's proposal.
>
> Let the discussion begin!
I am very glad, that you want to specify XNI extension, which could be
useful for xml tools usage. This extension sould support level 2 and 3 (as
you design above). Thanks.
Well, I would like to continue with discusion, so when you want (as I see)
to specify those extension interfaces, let's start specifing it.
Thanks for any answer.
Regards,
Libor