Quoting Ias <[EMAIL PROTECTED]>:

> jaxb.encoding is assigned for specifying the output encoding to which all
> the characters in the marshalled XML document should conform. The rule
> implies how a character maps to octet(s) in a stream rather than whether it
> must convert to a code point based notation. 

True. But as we still have to decide when to use code point notation or not,
at least for the default. And the decision

    "if mappable to octets in the current encoding"

is better than

    "if mappable in US ascii"

(which we have now).


> I also saw the XMLWriter for J2SE 1.4. Detecting whether a character can be
> encoded by the given charset by CharsetEncoder is efficient, but converting
> it to "&#ddd" in case of inencodability is a little questionable because
> CharsetEncoder has its own mechanism for those "unmappable character"s. (See
> CharsetEncoder in Java API doc for more details.) I'm not sure how JAXB spec
> describes this situation well, and probably we need to ensure what is the
> right behavior for a JAXB implementation by all means. If you don't mind,
> I'll ask JAXB spec lead about this issue.

As far as I can see, the CharSetEncoders replacement mechanisms sadly
cannot be used for out situation, because the replacement is always the
same, regardless of the input. And IMO the canEncode(char) method doesn't
consider replacements.

JAXB ignores the situation completely. I don't know the details of the
JAXB implementation, but I am quite sure, that the default implementation
simply uses an XSLT transformer, a SAXSource, and a StreamResult. (Which
I don't like, for reasons of performance.) However, feel free to ask anyone.
If possible, it would be nice to share the discussion with this list.
Perhaps Kohsuke can also comment on that?


> > I find this kind of customization to be much more desirable. 
> > In particular because it fits very well with the choice of 
> > XMLWriter14, if possible.
> >
> Yes, that's what I have hoped as well.  

Then I propose the following:

- We'll make "XMLWriter" an interface extending ContentHandler.
  The class has an additional method

    public void setWriter(Writer w)

  As an additional requirement any implementation must have a
  public constructor with no arguments.
- The current "XMLWriter" becomes "XMLWriterImpl".
- We'll add a new property "jaxme.xmlwriter" to the Marshaller.
  The property value is an instance of java.lang.Class implementing
  XMLWriter, by default the class XMLWriterImpl.
  The Marshallers method marshal(Object,Writer) becomes updated to
  create an instance of that class.
- Optionally: The default value is created from a private, static value.
  The value is initialized in a static class initializer: If

      Class.forName("java.lang.Charset")

  works, then it uses XMLWriter14, otherwise XMLWriterImpl.


Can we agree on that? If so, would you mind to provide a patch?


Regards,

Jochen



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
Jaxme-jaxb-dev mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxme-jaxb-dev

Reply via email to