I think some of my questions from my last post were lost in
the noise. Therefore, I'll restate them so that people can
comment, make suggestions, etc:

Should we modify the XMLDTDHandler to provide the following
information?

1) the non-normalized value for attribute type
2) The non-normalized value of attribute enumeration values
3) The non-normalized value for default attribute values

The idea is to emit more information about how parameter
entities are commonly used within a DTD. I'm not trying
to go "all the way" with this -- I'm just trying to find
a comfortable middle ground that is even useful for XML
editor writers.

The current attributeDecl prototype is this:

  void attributeDecl(String elementName, String attributeName,
                     String type, String[] enumeration,
                     String defaultType, XMLString defaultValue)

However, some common uses for parameter entities within
attribute declarations are listed below. I'm only talking 
about the external subset here, folks, because the internal 
subset can only contain parameter entities with WHOLE 
markup declarations in them.

1) parameter entity used for attribute type

<!ENTITY % string 'CDATA'>
<!ATTLIST elem attr %string; #REQUIRED>

2) parameter entity used for enumeration values

<!ENTITY % yesno 'yes|no'>
<!ATTLIST elem attr (%yesno;) #REQUIRED>

<!ENTITY % yesno '(yes|no)'>
<!ATTLIST elem attr %yesno; #REQUIRED>

3) parameter entity used for default value

<!ENTITY % default '"yes"'>
<!ATTLIST elem attr (yes|no) %default;>

However, adding non-normalized values for all of these
options will really blow the method prototype up and it's
already quite long to begin with. We could pass the 
non-normalized value for the entire declaration and push 
the burden to the application. But this might lead people 
to ask "why don't we do that for *all* the markup 
declarations?". It's such a nasty thought I don't even
want to think about it, though...

Comments?

-- 
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to