[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold scripsit:
> Anybody using a PrintStream to do serious work deserves the bugs they
> get. They've got problems before they even start thinking about XML.
I won't argue.
> Do you really mean to suggest that using UTF-8 code points as C chars
> is adequate? I suppose you could do that, but it most certainly is
> not convenient and completely fails your stated goal of making XML
> files plain text files. You're basically suggesting we treat them as
> binary data rather than text.
Not at all. C chars are octets, not characters.
> >The issue remains: XML files on the mainframe are not plaintext files
> >according to local conventions.
>
> Yes, that's true and the issue is *much* broader than merely adding
> NEL to the white space production. Even if we do this, XML files on
> mainframes will still not be plain text files. Adding NEL won't fix
> the problem.
Please clarify this.
> This whole notion of the "plain text" file may be a red herring. The
> community has realized over the last several years, that calling XML
> files plain text, really isn't accurate on any platform. Hence the
> move from text/xml to application/xml.
I support that move, but not because XML files are not plain text;
merely because they don't meet the overly restrictive definition of
text/plain used by MIME (since text/* should be able to fall back to
text/plain).
> You're confusing issues by merging together two different time
> frames: before and after XML 1.0 was released. Had IBM raised this
> issue during the development of XML, it could have been considered on
> different grounds. They failed to do so, and I see no justification
> for reopening the case now. It is far more important for XML to
> remain stable, than to allow a miniscule number of users (possibly as
> few as zero) not to upgrade their software to something that supports
> XML 1.0 conventions.
It seems to me that you are opposed in principle to changing 1.0, ever,
for any reason whatsoever. If that is so, it's pointless for us to go
on talking to/past each other.
> I find it completely reasonable to ask editors and other tools to
> support the line ending conventions of the files they're editing. I
> do this routinely on Mac, Windows, and Unix. I find it hard to
> believe that it is so much more difficult for mainframe programmers
> to do this.
Talk to IBM, not me.
> >Speaking for myself and not necessarily the Core WG, I agree that there
> >is no need to redefine the S production, merely to do line-terminator
> >mapping on input. IMHO, there is no reason for #xD to be part of S
> >either, as all real CRs are already mapped away, and having #xD be
> >part of S serves only to allow very strange abuse of character
> >references in entities containing attribute values and the like.
> >However, I am certainly not suggesting that #xD be removed from S.
> >
>
> Again, it's a time frame issue. We are not discussing what XML would
> be in an ideal world, had we known everything in 1996 that we know
> now. We are discussing what is best to do now. Failing to add NEL, in
> no way justifies removing CR.
I am not in any way justifying or suggesting removing CR from the S
production, as I say in plain words above. I am pointing out that neither
CR nor NEL belongs there on any rational justification, as far as I am
concerned. The S production can and should remain unchanged, changing only
the rules for line ending rationalization.
--
John Cowan <jcowan@reutershealth.com> http://www.reutershealth.com
I amar prestar aen, han mathon ne nen, http://www.ccil.org/~cowan
han mathon ne chae, a han noston ne 'wilith. --Galadriel, _LOTR:FOTR_
|
