[Xerces2] Non-Normalized Values Implemented

[Andy Clark]

I just committed the code to implement the non-normalized
value for internal entity declarations. I also implemented
the non-normalized value for attribute values. We had the
method in the XMLAttributes interface but it wasn't 
implemented before. (The next thing to do is remove the
various entity methods from the XMLAttributes interface.)

With these changes, you can get access more information
about how entities are used in the DTD and document. For
example:

  <!-- entities.dtd -->
  <!ENTITY % yesno 'yes|no'>
  <!ENTITY % yesnomaybe '%yesno;|maybe'>
  <!ENTITY candy 'M &amp; M'>

  <!-- document.xml -->
  <!DOCTYPE root SYSTEM 'entities.dtd'>
  <root attr='&candy;'/>

Before, you could get this information in the DTD handler 
and document handler:

  internalEntityDecl("%yesno", "yes|no")
  internalEntityDecl("%yesnomaybe", "yes|no|maybe")
  internalEntityDecl("candy", "M &amp; M")

  startElement("root", { "attr", "M & M" })

And now, you get this information:

  internalEntityDecl("%yesno", "yes|no", "yes|no")
  internalEntityDecl("%yesnomaybe", "yes|no|maybe", "%yesno;|maybe")
  internalEntityDecl("candy", "M &amp; M", "M &amp; M")

  startElement("root", { "attr", "M & M", "&candy;" })

The DTD information can be used to analyze how parameter
entities are used to define content models, etc. Pretty
cool.

I think this goes a long way to supporting the kind of
DTD information want to receive without requiring 50
billion methods to break apart each declaration. Some
examples of information we still can't convey to the
DTD handler:

  <!ENTITY % space ''>
  <!ENTITY % prefix 'a:'>
  <!ENTITY % name '%prefix;name'>
  <!ENTITY % yesno 'yes|no'>

  <!ELEMENT%space;%name;%space;(#PCDATA)>
  <!ATTLIST %name; choice (%yesno;) #REQUIRED>

You would not get any notification of the use of parameter
entities %space; and %name; within the declarations and
also would not be able to know the usage of %yesno; for
the enumerated values. 

I do not think we should try to support the first case.
However, we could support the second if we added another
similar parameter to the attributeDecl method. What do
people think?

Also, I'm wondering if we should provide the same 
information for the default attribute value in the
attribute decl. Right now the handler only sees the
normalized default attribute value.

Comments and suggestions are welcome.

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

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