[
Lists Home |
Date Index |
Thread Index
]
From: "John Cowan" <jcowan@reutershealth.com>
> "Exchanging" is practical, if by that you mean a translation process
> is used and the data is in migration. But if the data were directly
> *shared* via NFS, that would be another matter.
In http://www.w3.org/TR/newline the three use cases are:
> Processing documents that arrive on OS/390 systems through FTP from UNIX systems
These documents are declared invalid or not well-formed by XML 1.0 compliant parsers running on DOS or UNIX-based systems because the documents contain [NEL] characters in element content or in places where only white space is allowed.
But FTP deals with sending EBCDIC and sending ASCII. It says nothing about the
mapping to be used from Unicode to and from EBCDIC. This only requires mapping
NEL to xA in import, and no changes to S production, and/or specifying that serialization
to EBCDIC may/should generate NEL not #A
> Processing documents retrieved on DOS or UNIX-based systems via JDBC from mainframe database systems, where the documents were created on OS/390 systems
These documents are rejected by XML 1.0 compliant parsers running on DOS or UNIX-based systems because the documents contain [NEL] characters in places where only white space is allowed.
This only requires mapping NEL to #A on input, not adding to the S production.
And/or specifying that serialization to EBCDIC may/should generate NEL not #A.
> Using native system string functions, such as atoi and atof, to convert XML strings, documents, or fragments, to other data types
These string functions recognise [NEL], and do not recognise [LF] as white space. Usually, the regular programming facilities of an OS/390 platform cannot be used to process nor to generate XML 1.0 compliant documents.
Which are the "regular programming facilities", I wonder? If they are using any standard
programming language, then there are routines to perform *basic* string operations such
as these. If the regular programming facilities don't even reach that level, IBM should provide
better APIs, not blame the messenger.
I do not believe that any of the three use cases provided by IBM justify changing the S
production. However, treating it as a newline/transcoding issue is appropriate.
Cheers
Rick Jelliffe
|
