[dsdl-discuss] Re: Does Part 7 need built-in definitions for IANA sets?

MURATA Makoto wrote:

>At present, different implementations do different things.
>If Part 7 is based on IANA charsets, we cannot have interoperability.
>
I think we still can. But I am not proposing that Part 7 be based on
IANA charsets:
merely that in addition to hulls and kernels, Part 7 should have a way of
invoking the platform's built-in transcoders and testing the document
against those.
This gives different, but useful information.

Where the platform-provided, IANA-named sets are unsatisfactory, the
normal hulls
and kernels mechanism can be used. SBCS don't have the same problems with
versioning that DBCS have (despite Europe's best efforts to add Euros
here and there :-).
The IANA names are perfectly adequate for most SBCS AFAIK, and it would
be very
useful for implementers and users to start with a large range of tests
available.

I think there are three different issues:

1) Does a document conform to a standard repertoire?
2) Does a document conform to a plaform's implemenation of a standard
repertoire?
3) Does a platform's implementation of a standard repertoire conform to
that?

Hulls and kernels allows testing much of 1), to the extent that the data
is not already corrupt
by having yens and / swapped, etc.
 
Using the platform's charset allows testing of 1) for SBCS, and 2) for
SBCS and DBCS.
(Whether the platform actually faithfully implements the IANA etc name,
and whether
the IANA charset is precise enough, comes under issue 3))

The issue of 3) may be out of scope for CharRep. However, if CharRep
implements
solutions to both 1) and 2) , the CharRep can be used to test 3)!
You make a document with all unicode characters. You make one schema with
the JIS sets. You make another schema with the IAN name. You validate
the document
against both. You compare results.

Cheers
Rick Jelliffe

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)