Hi,
the implementor of the previous patch has not got back to us with
an updated patch since the middle of last month. I suggest we apply your
patch so we definitely have a pretty print in the next release. If we need
to change it we still can. Send me the patch and I will review and app
odd - i sent this the other day but it never came through - resending now... :
Hello - thought I should get back into this thread since I started it
all. I've been sitting back observing since alot of the discussion is
above my current XML knowledge. In any case it appears that a general
cons
p - thanks.
Gareth Reakes <[EMAIL PROTECTED]>
03/12/2002 04:31 AM
Please respond to xerces-c-dev
To: [EMAIL PROTECTED]
cc:
Subject: Re: FormatPrettyPrint implementation
Hi all,
I don't want this thread to disappear i
Hi all,
I don't want this thread to disappear into oblivion again so this
is the last chance to speak up. Duncun, have you or do you intend to
query the DOM WG on the issues you raised?
Gareth
--
Gareth Reakes, Head of Product Development +44-1865-203192
DecisionSoft Limited
Hi,
On Wed, 27 Nov 2002 [EMAIL PROTECTED] wrote:
> wrt to fitting in with spec.
> If an element is defined as mixed by a DTD then you can't insert or remove
> white space for the purposes of being 'human readable' because if the
> whitespace is important then what the human reads (after pretty
My 2 cents on the FormatPrettyPrint issue:
The XML applications that we write are always able to
process XML written by humans (or monkeys, who
knows..) and XML that is machine generated. The
machine generated XML might or might not have any
white space, the manually XML documents are almost
alway
To: [EMAIL PROTECTED]
cc:
Subject: Re: FormatPrettyPrint implementation
Hi,
I don't see how we would fit that in with the spec. It states
"Formatting the output by adding whitespace to produce a pretty-printed,
indented, human-readable form.
"Gareth Reakes" <[EMAIL PROTECTED]> writes:
> The way I had been thinking (I am of course happy to be told I am
> wrong :)) is that it did not really matter as long as it was
> consistent. I felt that the purpose of this feature was literally to
> pretty print and not to worry about validity. With
Hi,
I don't see how we would fit that in with the spec. It states
"Formatting the output by adding whitespace to produce a pretty-printed,
indented, human-readable form. The exact form of the transformations is
not specified by this specification. Setting this feature to true will set
I don't know. You might want to query the patch author directly (or copy him
on a post to the list) in case he doesn't subscribe.
-Original Message-
From: Kevin King [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 4:58 PM
To: [EMAIL PROTECTED]
Subject: RE: FormatP
areth Reakes <[EMAIL PROTECTED]>
21/11/2002 09:56 PM
Please respond to xerces-c-dev
To: [EMAIL PROTECTED]
cc:
Subject: Re: FormatPrettyPrint implementation
Hi,
nice work :). The spec does not say how the pretty printing sho
I was unaware that some work at already been done. I tried to apply the
patch that is referenced below but keep getting errors. What version of
the files is the diff against?
-Kevin
At 09:26 AM 11/21/2002 -0500, you wrote:
See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13840 for anothe
See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13840 for another
implementation.
-Original Message-
From: Kevin King [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 2:12 AM
To: [EMAIL PROTECTED]
Subject: FormatPrettyPrint implementation
Hello,
I should probably first
Hi,
nice work :). The spec does not say how the pretty printing should
work so if no one has any objections to the way you have done it then I
suggest we commit it and see what users say. I know many people ask for
this functionality.
Gareth
On Thu, 21 Nov 2002, Kevin King wrote:
>
14 matches
Mail list logo
