docutils-users

Re: [Docutils-users] Scientific article example

[Paul T. <pau...@gm...>]

On 10/18/11 12:34 AM, Aahz wrote:
>
> Yeah, right.
>
> (In case anyone isn't clear, that's an example of an inverted double
> positive.  Double-plus good!)
Such unbad good speak does not displease me.

Re: [Docutils-users] Scientific article example

[Alan G I. <ai...@am...>]

>> My view is that your citation should specify the volume,
>> although obviously your field may have a different
>> practice.  In any case [mykey{page:197,volume:2}]_ does
>> what you want.

> No, not at all, because that undermines the whole purpose
> of bibliographic management, that you specify the minimal
> data, and let the formatter format it. In this case, there
> are two different bits of data, along with the key: the
> page number, and the volume. MLA may require that you
> write "p. 55, vol. 2" whereas another publication may
> require that you write "page:197, Volume:2".

In that case, use a different key for each citation,
and then use a style that formats that key in any way you find useful.
So you really should be creating a separate **database entry** for each
volume, and then rely on a formatter-style for citation creation.
E.g., see Bibtex's conventions.


> but I'm not sure what you mean by "too implicit."

You are proposing conventions that are not unambiguous
and (as a result) not readily extensible.

Be sure to distinguish citations and citation references.
As things stand, it is already possible to handle citation
formatting using e.g. bibstuff.  You can also use bibstuff
to substitute text for citation references, to a certain
extent.  The problem is that that reST provides no syntax
for associating *instance-specific* information with a
particular instance of a citation reference.  I'm just
proposing a *syntax* for doing that.  It has *no* implications
for what will be done with that info (e.g., how it will be
formatted).

In any case, no developer has expressed interest so far.

Cheers,
Alan

Re: [Docutils-users] Scientific article example

[Paul T. <pau...@gm...>]

On 10/17/11 4:35 PM, Alan G Isaac wrote:
>>> My view is that your citation should specify the volume,
>>> although obviously your field may have a different
>>> practice.  In any case [mykey{page:197,volume:2}]_ does
>>> what you want.
>> No, not at all, because that undermines the whole purpose
>> of bibliographic management, that you specify the minimal
>> data, and let the formatter format it. In this case, there
>> are two different bits of data, along with the key: the
>> page number, and the volume. MLA may require that you
>> write "p. 55, vol. 2" whereas another publication may
>> require that you write "page:197, Volume:2".
> In that case, use a different key for each citation,
> and then use a style that formats that key in any way you find useful.
> So you really should be creating a separate **database entry** for each
> volume, and then rely on a formatter-style for citation creation.
> E.g., see Bibtex's conventions.

But again, that undermines the whole purpose of having a bibliographic 
system. A bibliographic system should do the formatting for me, without 
my having to enter in a new database for each style. If I followed your 
recommendation, and I had 500 entries, I would have to re-type all 500 
entries. What would be the point of having a bibliographic system? The 
idea behind bibliographic management is to avoid such redundancy. 
Theoretically, I would be able to write on RST document and submit it to 
a journal. I should be able to choose the formatting of my citations. 
Then, if I needed to submit my article to another journal that required 
a different style, I would not have to change anything; I could simply 
choose a different style.
>> but I'm not sure what you mean by "too implicit."
> You are proposing conventions that are not unambiguous
> and (as a result) not readily extensible.

I don't see how you can say this. I already provide one line of code 
that can clearly parse the information in a non ambiguous way. I 
actually like your way, but stated we could mix the pattern if there was 
only a page number. The page number is simply the text after the citation:

if "}" not in cit_text:
     fields = cit_text.split()
     if len(fields) > 1:
         page_num = fields[1]
     else:
         # parse {page:x} etc

There is nothing ambiguous about that.
>
> Be sure to distinguish citations and citation references.
> As things stand, it is already possible to handle citation
> formatting using e.g. bibstuff.  You can also use bibstuff
> to substitute text for citation references, to a certain
> extent.  The problem is that that reST provides no syntax
> for associating *instance-specific* information with a
> particular instance of a citation reference.  I'm just
> proposing a *syntax* for doing that.  It has *no* implications
> for what will be done with that info (e.g., how it will be
> formatted).
>
>
I assume a citation has to be formatted in some way, beyond a key word. 
That is certainly the case for many articles in the humanities. I cannot 
use bibtex because I do not use LaTeX. RST is supposed to be more than a 
front end for LaTeX, right?

You write: "The problem is that that reST provides no syntax
for associating *instance-specific*"

Sorry, but I really don't know what you mean by "instance-specific."

Paul

Re: [Docutils-users] Scientific article example

[Paul T. <pau...@gm...>]

On 10/17/11 5:36 PM, Alan G Isaac wrote:
> On 10/17/2011 4:46 PM, Paul Tremblay wrote:
>> I don't know why you insist on being so pedantic
> Love of language.
>
> If you want the closest there is to a standard,
> look at rfc 4180.
> http://tools.ietf.org/html/rfc4180#page-2 (point 4)
>
> CSV = **comma** separated values, no matter what
> various tools will parse.
>
>

Then you would know that language takes meaning in the way it is used. 
In this case, everyone understands that CSV means a file separated by 
delimeters chosen by the user.

I mean, if you go to the Python page I liked to, the very first example 
given for the CSV reader is a *space delimited* file. OpenOffice and 
Word also consider space delimited files to be CSV. So no, CSV does not 
mean "comma" separated. So apparently everyone in the world has CSV 
wrong, except Alan? Is that really how you think language is used?

Paul

Re: [Docutils-users] Scientific article example

[Alan G I. <ai...@am...>]

> On 10/17/11 4:35 PM, Alan G Isaac wrote:
>> see Bibtex's conventions.

On 10/17/2011 5:11 PM, Paul Tremblay wrote:
> that undermines the whole purpose of having
> a bibliographic system.

Are you familiar with BibTeX?
I hardly think you can make that case.

> If I followed your recommendation, and I had 500 entries,
> I would have to re-type all 500 entries.

Not at all. You would have *one* database.  The entries
would be **formatted** based on a style file.  This is
the BibTeX approach.  (It is also the approach used
by bibstuff to format citations.)

> we could mix the pattern if there was only a page number.
> The page number is simply the text after the citation:

It is better to say what it is.
If it is a page number, say so explicitly.
Don't rely on a convention that may mystify others.

> I cannot use bibtex because I do not use LaTeX. RST is
> supposed to be more than a front end for LaTeX, right?

Yes, but it's inadequate citation handling is an
acknowledged shortcoming and, in fact, there is no developer
commitment (at this point) to change that.  However you can
still get part of what you want from bibstuff.

> Sorry, but I really don't know what you mean by
> "instance-specific."

There may be many citation references to the same citation.
Each reference instance may need information specific
to that instance. (The most common example is a page
number.) We need some way to provide such instance specific
information while still referencing a shared citation.
That is the reason for my proposal, which has **absolutely
nothing** to say about formatting of the output.

I want to stress that I am a user, not a developer, and that
to my memory only Guenter has expressed much interest in
seeing an improvement in citation support.  (I think David
at one point even doubted the appropriateness of attempting this.)

Cheers,
Alan

Re: [Docutils-users] Scientific article example

[Alan G I. <ai...@am...>]

On 10/17/2011 5:44 PM, Paul Tremblay wrote:
> everyone understands that CSV means a file separated by delimeters chosen by the user.


http://tools.ietf.org/html/rfc4180#page-2 (point 4)

http://en.wikipedia.org/wiki/Delimiter-separated_values

(I did not write the Wikipedia entry.)

Cheers,
Alan

Re: [Docutils-users] Scientific article example

[Paul T. <pau...@gm...>]

On 10/17/11 5:36 PM, Alan G Isaac wrote:
> On 10/17/2011 4:46 PM, Paul Tremblay wrote:
>> I don't know why you insist on being so pedantic
> Love of language.
>
> If you want the closest there is to a standard,
> look at rfc 4180.
> http://tools.ietf.org/html/rfc4180#page-2 (point 4)
>
>
By the way, from the top of your own link:

"This memo provides information for the Internet community. It does not 
specify an Internet standard of any kind. Distribution of this memo is 
unlimited."

If you export from Excel or OpenOffice to a CSV format, you are allowed 
to use any delimeter. You can
choose the "|" character or "a" character. And when you open those same 
files, lo and behold!--they appear exactly as you exported them. You 
want to call space delimited files "SSV." So know what do we call files 
delimited by "|" or "a"--BSV (Bar Separated Values) and ASV (A Separated 
Values)?  How silly do we want to be?

And as a linguistic exercise, what do you think of when you hear the 
word "band aid?" What do we mean by the word "hound." (Hint: what is 
linguistic narrowing?)

Paul

Re: [Docutils-users] Scientific article example

[Paul T. <pau...@gm...>]

On 10/17/11 5:53 PM, Alan G Isaac wrote:
> On 10/17/2011 5:44 PM, Paul Tremblay wrote:
>> everyone understands that CSV means a file separated by delimeters chosen by the user.
>
> http://tools.ietf.org/html/rfc4180#page-2 (point 4)
>
> http://en.wikipedia.org/wiki/Delimiter-separated_values
>
> (I did not write the Wikipedia entry.)
>
And from your own link:

" Any character or sequence of characters may be used to separate the 
values, but the most common delimiters are the comma 
<http://en.wikipedia.org/wiki/Comma_%28punctuation%29>, tab 
<http://en.wikipedia.org/wiki/Tab_stop>, and colon 
<http://en.wikipedia.org/wiki/Colon_%28punctuation%29>.^[1] 
<http://en.wikipedia.org/wiki/Delimiter-separated_values#cite_note-artofunix-0> 
^[2] 
<http://en.wikipedia.org/wiki/Delimiter-separated_values#cite_note-1> 
The vertical bar <http://en.wikipedia.org/wiki/Vertical_bar> (also 
referred to as /pipe/) and space 
<http://en.wikipedia.org/wiki/Space_%28punctuation%29> are also 
sometimes used."

And you still want to insist on a meaning not accepted by anyone else? 
Maybe you should write your own dictionary.

Paul^<http://en.wikipedia.org/wiki/Delimiter-separated_values#cite_note-artofunix-0> 

Re: [Docutils-users] Scientific article example

[Ben F. <ben...@be...>]

Paul Tremblay <pau...@gm...> writes:

> You want to call space delimited files "SSV." So know what do we call
> files delimited by "|" or "a"--BSV (Bar Separated Values) and ASV (A
> Separated Values)? How silly do we want to be?

Alan hasn't advocated any of those names, AFAICT.

The existing name which covers all of those, including tab-separated and
comma-separated, is DSV: Delimiter-Separated Values.

> And as a linguistic exercise, what do you think of when you hear the word
> "band aid?"

I think “another brand name has wormed its way into the language as a
generic term, and I will resist it as far as I am able” :-)

-- 
 \          “What I have to do is see, at any rate, that I do not lend |
  `\      myself to the wrong which I condemn.” —Henry Thoreau, _Civil |
_o__)                                                    Disobedience_ |
Ben Finney

Re: [Docutils-users] Scientific article example

[Paul T. <pau...@gm...>]

On 10/17/11 6:04 PM, Ben Finney wrote:
> Paul Tremblay<pau...@gm...>  writes:
>
>> You want to call space delimited files "SSV." So know what do we call
>> files delimited by "|" or "a"--BSV (Bar Separated Values) and ASV (A
>> Separated Values)? How silly do we want to be?
> Alan hasn't advocated any of those names, AFAICT.
>
> The existing name which covers all of those, including tab-separated and
> comma-separated, is DSV: Delimiter-Separated Values.
>
>> And as a linguistic exercise, what do you think of when you hear the word
>> "band aid?"
> I think “another brand name has wormed its way into the language as a
> generic term, and I will resist it as far as I am able” :-)
>

But of course, you are avoiding the issue: language takes its meaning on 
how it is used, not on some arbitrary definition. Everyone knows what 
CSV means. If DSV were really the right term, then why does Python, 
OpenOffice, and MS all get it wrong?

Paul

Re: [Docutils-users] OT: DSV vs CSV

[Alan G I. <ai...@am...>]

> "This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited."

That is just the nature of an RFC:
http://en.wikipedia.org/wiki/Request_for_Comments

As I said, this is the **closest** there is to a standard:
http://tools.ietf.org/html/rfc4180#page-2  (point 4)


> So know what do we call files delimited by "|" or "a"--BSV (Bar Separated Values) and ASV (A Separated Values)?

DSV: http://en.wikipedia.org/wiki/Delimiter-separated_values

But an even better idea is to agree on a standard delimiter.
(E.g., the comma.)

Cheers,
Alan

Re: [Docutils-users] OT: DSV vs CSV

[Paul T. <pau...@gm...>]

On 10/17/11 6:05 PM, Alan G Isaac wrote:
>> "This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited."
> That is just the nature of an RFC:
> http://en.wikipedia.org/wiki/Request_for_Comments
>
> As I said, this is the **closest** there is to a standard:
> http://tools.ietf.org/html/rfc4180#page-2  (point 4)

Which of course, does not prove your point. Someone proposed a standard, 
that has not been accepted, that no one else accepts. The very Wiki 
entry to linked me to contradicted what you claimed. Do you really think 
Python, OpenOffice, and MS all got this wrong?
>
>
>> So know what do we call files delimited by "|" or "a"--BSV (Bar Separated Values) and ASV (A Separated Values)?
> DSV: http://en.wikipedia.org/wiki/Delimiter-separated_values
>
>
No one refers to such files as DSV. Nor is it necessary to use just 
comas. If many of your fields contain comas, you wouldn't want to, and 
the files are just as readable and parsable.

So to repeat my point, no, I didn't mean "space delimited." I meant CSV, 
using it the way everyone else does.

Paul

Re: [Docutils-users] Scientific article example

[Paul T. <pau...@gm...>]

On 10/17/11 5:50 PM, Alan G Isaac wrote:
>> On 10/17/11 4:35 PM, Alan G Isaac wrote:
>>> see Bibtex's conventions.
> On 10/17/2011 5:11 PM, Paul Tremblay wrote:
>> that undermines the whole purpose of having
>> a bibliographic system.
> Are you familiar with BibTeX?
> I hardly think you can make that case.

What case? It would help if you could be specific so we could move the 
conversation along, rather than throwing out ambiguous phrases.
>
>> If I followed your recommendation, and I had 500 entries,
>> I would have to re-type all 500 entries.
> Not at all. You would have *one* database.  The entries
> would be **formatted** based on a style file.  This is
> the BibTeX approach.  (It is also the approach used
> by bibstuff to format citations.)

Agree. But within the text, you have to include info not in the 
database--such as page and volume number. I did quite a bit of work in 
the past in this area, which is why I insist on this point.
>
> It is better to say what it is.
> If it is a page number, say so explicitly.
> Don't rely on a convention that may mystify others.

It won't mystify others if we have a standard that is documented. After 
all, the very convention for a citation [xxx]_ is mystifying unless you 
know restructured markup. Obviously, as with anything in 
restructuredtext, we want to provide a balance between a user being able 
to read it and python being able to parse the file. I would think 
[author 8] meets both those criteria.
> Yes, but it's inadequate citation handling is an
> acknowledged shortcoming and, in fact, there is no developer
> commitment (at this point) to change that.  However you can
> still get part of what you want from bibstuff.

If I am not using bibstuff, how do I get info from it? Sorry if I am 
missing something.
> There may be many citation references to the same citation.
> Each reference instance may need information specific
> to that instance. (The most common example is a page
> number.) We need some way to provide such instance specific
> information while still referencing a shared citation.
> That is the reason for my proposal, which has **absolutely
> nothing** to say about formatting of the output.
>
>
Okay, Alan, then we absolutely agree on this. I mean the same thing and 
I am trying to achieve the same thing. However, you need more info for 
the specific "instance" than just the page number. We have to agree on a 
system that handles all situations. From my past experience of working 
on this, I know that citation info is often more complex than people 
think. None-the-less, we are both trying to achieve the same thing, and 
I agree that on first glance, your proposal seems better than my initial 
one.

Paul

Re: [Docutils-users] OT: DSV vs CSV

[Alan G I. <ai...@am...>]

On 10/17/2011 5:58 PM, Paul Tremblay wrote:
> And from your own link:
> " Any character or sequence of characters may be used to
> separate the values, but the most common delimiters are
> the comma, tab, and colon

You did not read this carefully.  You are quoting the the
definition of **DSV**.  The full quote is
http://en.wikipedia.org/wiki/Delimiter-separated_values
"Any character or sequence of characters may be used to
separate the values, but the most common delimiters are the
comma, tab, and colon.[1] [2] The vertical bar (also
referred to as pipe) and space are also sometimes used.[1]
In a comma-separated values (CSV) file the data items are
separated using commas as a delimiter, while in
a tab-separated values (TSV) file, the data items are
separated using tabs as a delimiter."

Cheers,
Alan

Re: [Docutils-users] OT: DSV vs CSV

[Paul T. <pau...@gm...>]

On 10/17/11 6:15 PM, Alan G Isaac wrote:
> On 10/17/2011 5:58 PM, Paul Tremblay wrote:
>> And from your own link:
>> " Any character or sequence of characters may be used to
>> separate the values, but the most common delimiters are
>> the comma, tab, and colon
>
Sorry, you are correct. But of course, I am still correct in my 
definition of CSV, as it is understood by OpenOffice, python, and MS. 
Language does have meaning on how it is used, as I hinted with the word 
band aid.

Paul

Re: [Docutils-users] Scientific article example

[Alan G I. <ai...@am...>]

On 10/17/2011 6:10 PM, Paul Tremblay wrote:
> within the text, you have to include info not in the database--such as page and volume number


Right.  And we need the developers to choose a simple
yet easily extensible syntax for that.  I hope that
my proposal of terminal, braces-delimited text within
a citation reference will receive developer consideration.

It is important that people like you are making the point
that this functionality would be a very desirable addition to reST.
It would be nice even to have an agreement in principle
on that from the current developers.

Cheers,
Alan

Re: [Docutils-users] OT: DSV vs CSV

[Paul T. <pau...@gm...>]

On 10/17/11 6:05 PM, Alan G Isaac wrote:
>
> But an even better idea is to agree on a standard delimiter.
> (E.g., the comma.)
>
>

Actually, that is not such a good idea. From the Wiki entry on CSV:

" Microsoft Excel <http://en.wikipedia.org/wiki/Microsoft_Excel> will 
open .csv files, but depending on the system's regional settings, it may 
expect a semicolon <http://en.wikipedia.org/wiki/Semicolon> as a 
separator instead of a comma, since in some languages the comma is used 
as the decimal separator <http://en.wikipedia.org/wiki/Decimal_separator>"

The actual delimiter is not important. I have actually written a XSLT 
stylesheet that parses CSV. The hard part is ot the delimiter. In fact, 
there really is no hard part.

But just to emphasize this point, people often send me results from 
races which I have to parse. They normally send them as space separated, 
since that is how they appear in tables, how they are used to seeing 
them. It would be extra work for them to require that they put commas 
in. When I get the files I use a CSV program to interpret the data.

Paul

Re: [Docutils-users] Scientific article example

[Paul T. <pau...@gm...>]

On 10/17/11 6:28 PM, Alan G Isaac wrote:
> On 10/17/2011 6:10 PM, Paul Tremblay wrote:
>> within the text, you have to include info not in the database--such as page and volume number
>
> Right.  And we need the developers to choose a simple
> yet easily extensible syntax for that.  I hope that
> my proposal of terminal, braces-delimited text within
> a citation reference will receive developer consideration.
>
> It is important that people like you are making the point
> that this functionality would be a very desirable addition to reST.
> It would be nice even to have an agreement in principle
> on that from the current developers.
>
>
I agree. I think the reason this has not been implemented yet is that 
such a system is complicated. Can someone help me out--I believe this is 
the case. Not only would there have to be agreement on the actual 
"instance" (what you call the page number, etc.), but agreement on how 
to create a database, and then how to manage the formatting. It gets 
incredible tricky. For example, you might have:

[author 33]_ .....text [author 55]_

Many styles require that you format these as:

last name, first name *book* pub, year (etc.), p 33

Ibid p 55

So you actually have to look at the previous entry and see if it matches 
completely (in which case you use "ibid,"), or if it just matches the 
author, in which case you use "ibid, p 55."  Then you have to write 
different rules for the dozens and dozens of different styles.

I believe this is the reason it has not been implemented yet.

Paul

Re: [Docutils-users] Scientific article example

[Alan G I. <ai...@am...>]

On 10/17/2011 6:43 PM, Paul Tremblay wrote:
> Not only would there have to be agreement on the actual
> "instance" (what you call the page number, etc.), but
> agreement on how to create a database, and then how to
> manage the formatting.

We do not need to address all that until later.

The first thing we need is a way to attach instance-specific
information to citation references.

Once this is done, we are free to find any way to use
that information that we wish.

For example, bibstuff already produces formatted citations
from a standard Bibtex database.  Another application might
use another type of database.  The priority is that docutils
support providing the information that such applications need.

I'm hoping Guenter will speak to this...

Cheers,
Alan

Re: [Docutils-users] OT: DSV vs CSV

[Alan G I. <ai...@am...>]

> On 10/17/11 6:05 PM, Alan G Isaac wrote:
>> But an even better idea is to agree on a standard
>> delimiter.  (E.g., the comma.)

On 10/17/2011 6:33 PM, Paul Tremblay wrote:
> Actually, that is not such a good idea. From the Wiki
> entry on CSV:

> " Microsoft Excel will open .csv files, but depending on
> the system's regional settings, it may expect a semicolon
> as a separator instead of a comma, since in some languages
> the comma is used as the decimal separator


This just pushes the need for standards back one step.
One problem is dual standards for the decimal delimiters.
Sooner or later something really bad will happen due to this.
I urge and expect that scientific computing use only
the decimal point standard.

And that CSV not be used to mean DSV, of course.

Cheers,
Alan

Re: [Docutils-users] OT: DSV vs CSV

[Paul T. <pau...@gm...>]

On 10/17/11 6:49 PM, Alan G Isaac wrote:
>
>
> This just pushes the need for standards back one step.
> One problem is dual standards for the decimal delimiters.
> Sooner or later something really bad will happen due to this.
> I urge and expect that scientific computing use only
> the decimal point standard.
>
> And that CSV not be used to mean DSV, of course.
>
>
That's just nonsense. Have you even ever worked with CSV? The rules are 
very simple, and nothing will break, which is why Python's parser, as 
well as implementations by OO an MS work just fine. You have zero basis 
in wanting the computer based community to use just commas for CSV.

Paul

Re: [Docutils-users] OT: DSV vs CSV

[Alan G I. <ai...@am...>]

On 10/17/2011 6:22 PM, Paul Tremblay wrote:
> I am still correct in my
> definition of CSV, as it is understood by OpenOffice, python, and MS.


Not really.
Export a file as CSV from say Excel.
You don't get a request for a delimiter specification.
You get a comma (unless you mucked with the regional settings).

I do not deny that some people use the term CSV to mean DSV,
as you do, but the more careful they become (e.g., if they propose
a standard), the less likely that becomes.

The real background point is that it is desirable for CSV
to mean CSV, and not DSV, because it removes an important ambiguity
(for both parsing and writing).

Alan

Re: [Docutils-users] OT: DSV vs CSV

[Paul T. <pau...@gm...>]

On 10/17/11 6:51 PM, Alan G Isaac wrote:
> On 10/17/2011 6:22 PM, Paul Tremblay wrote:
>> I am still correct in my
>> definition of CSV, as it is understood by OpenOffice, python, and MS.
>
> Not really.
> Export a file as CSV from say Excel.
> You don't get a request for a delimiter specification.
> You get a comma (unless you mucked with the regional settings).
>
> I do not deny that some people use the term CSV to mean DSV,
> as you do, but the more careful they become (e.g., if they propose
> a standard), the less likely that becomes.
>
> The real background point is that it is desirable for CSV
> to mean CSV, and not DSV, because it removes an important ambiguity
> (for both parsing and writing).
>
> A
I don't have excel here, but at work you certainly can easily change the 
setting when you save the file, unless my memory serves me wrong. 
However, I just opened OO and was given the option. Certainly, MS will 
open many different types of CSV files.

You really need to think about this. If you think different delimiters 
would break the system, then why does Python not only allow this, but 
has as its first example a file separated by spaces? As I've said 
before, I've actually written code in XSLT to munge CSV; the delimiter 
does not matter.

If you think otherwise, can you please provide a concrete example so 
this discussion can move forward?

Paul

Re: [Docutils-users] OT: DSV vs CSV

[Alan G I. <ai...@am...>]

On 10/17/2011 7:07 PM, Paul Tremblay wrote:
> the delimiter does not matter.
>
> If you think otherwise, can you please provide a concrete example


Parse this:
32.654,32

You won't know how unless I tell you what the delimiter is.

But of course the whole idea of a "concrete example" misses
the point.  A format is useful if I do not need to examine
the data to read it in without ambiguity.  Playing around
with the delimiters makes a mess of what could be clean.

*That* is the role of standards.
To remove such silly ambiguities.

And *that* is why DSV can never become a *standard*,
but CSV can.  And it is why people who care about
scientific data draw the distinction. (Although we
can imagine a DSV-like standard that uses the first
line to specify a delimiter.)

Alan

Re: [Docutils-users] OT: DSV vs CSV

[Paul T. <pau...@gm...>]

On 10/17/11 10:00 PM, Alan G Isaac wrote:
> On 10/17/2011 7:07 PM, Paul Tremblay wrote:
>> the delimiter does not matter.
>>
>> If you think otherwise, can you please provide a concrete example
>
> Parse this:
> 32.654,32
>
> You won't know how unless I tell you what the delimiter is.
>
> But of course the whole idea of a "concrete example" misses
> the point.  A format is useful if I do not need to examine
> the data to read it in without ambiguity.  Playing around
> with the delimiters makes a mess of what could be clean.
>
> *That* is the role of standards.
> To remove such silly ambiguities.
>
> And *that* is why DSV can never become a *standard*,
> but CSV can.  And it is why people who care about
> scientific data draw the distinction. (Although we
> can imagine a DSV-like standard that uses the first
> line to specify a delimiter.)
>
>
Alan, it might be better if you actually learned how CSV worked before 
posting such silliness. You are wasting my time and probably everyone 
else  as well. It is one thing to argue semantics over DSV vs CSV, but 
quite another to wade into an area about which you (apparently) know 
nothing. You ask me how to parse a string in which I don't know the 
delimiter, but you might as well ask me to parse a file when I don't 
know the path or the encoding. The delimiter must be given

There are no standards for CSV. And if a standard gets passed that 
enforces commas for the delimiter, then that still doesn't change 
anything. The code would still exist to parse files that use different 
delimiters, and such files are quite useful. As I've stated before, I 
actually use space delimited files quite a bit.

If you think this suggestion is so outlandish, maybe you should check here:

delim : char | "tab" | "space"

     A one-character string used to separate fields. Defaults to , 
(comma). May
     be specified as a Unicode code point; see the unicode directive for 
syntax
     details.

Where am I getting his instruction that CSV can use spaces and tabs? 
Why, from the very documentation of resturedtext itself!

http://docutils.sourceforge.net/docs/ref/rst/directives.html#id1

Given that python has a whole library that uses different delimiters 
than a comma; and given that OO and MS do the same; and given that 
restructuredtext also follows the same practice (calling is CSV and not 
DSV), perhaps you just might consider that you are wrong?

Now maybe I can get back to actually working on problems in  
restructuredtext, like putting in MathML for the XML writer.

Paul