Hello Friedrich. Are you the same person who has been calling himself/herself
something like "senior tyrtle"?
Frierich Munch wrote:
> On 7/24/05 2:29 PM, "Julian Foad" <julianfoad@btopenworld.com> sneezed:
>>Trying to parse property values into one of a number of different types seems
>>to me inappropriate here. That cannot be done correctly without knowing what
>>type of information each individual property contains.
>
> I think it's really beneficial. It's not command-line output, and I think
> it should be as stateful as possible.
If it was guaranteed to be correct I can see how it would be beneficial. What
I don't understand is how a guess can be useful.
The word "stateful" doesn't have a precise meaning in this context, so I'm not
sure what you mean by that.
> Being said, I'm the first to acknowledged it's a bit akward. Compromise:
>
> All values go into <values></values> tags. This really should be how it is
> anyway, making room for inheritance to be expressed. Express type in a
> "type" or uglier "possible_type" attribute.
(In this compromise, I think you are implying that the value would always be
expressed as a plain string or base-64, and an attribute would indicate a best
guess at the type of the value.)
That compromise would certainly be free from the data-loss problem.
"possible_type" would certainly be a more accurate name for the attribute than
"type".
> 99.9% of the time the deduction of value will be accurate.
I dispute that. What is your evidence? In your current patch, it looks like
numbers beginning with a "minus" sign will not be recognised as numbers.
You'll say that's "just a bug" but that's far from the only problem, it's just
one example. For example, there is no clear answer to the following questions:
Should numbers beginning with a decimal point be allowed? What about a comma
instead of a decimal point? What about leading white space? What date formats
should it recognise? etc.
> For the times that its not, it is still a lossless operation, as the value
> is always output as a string. The attribute is more of a hint (this value
> was found to be capable o being expressed as) which would be far worse (in
> my opinion) to deduce in xslt, and as the only user so far, is needed.
I am finding it very difficult to imagine why anyone (e.g. in XSLT) would want
a hint about what the type of a particular property value looks like. The only
purpose I can think of is to format the value for display to a human being,
because then the value can be made to look nicer (e.g. numbers being
right-aligned) when the hint is correct, but will still be understandable if
the hint is wrong.
However, if that's the primary use case, I don't think that Subversion should
be the part of the system that makes that guess. It would be wrong and
unmaintainable for Subversion to have the knowledge about what different sorts
of property values you want to display in different ways. If it's difficult to
do in XSLT, use something else.
If that's not the primary use case, please say what is, in enough detail for me
to understand why this behaviour is useful.
> If this still doesn't work for you, can this be opened on to users@svn to
> see how most users would prefer.
Yes, you can ask the users there for their opinions, if you like. Collect the
information you get and present a summary of it here, being sure to give
concrete reasons for why certain behaviours are wanted.
>
>>If your goal is to have the known "svn:" properties parsed and presented
>>specially
>
> That's not the goal. The goal is to represent information as stateful as
> possible. I think special casing svn properties is more of a pain to
> maintain.
That's not a sufficient explanation of your goal. Special-casing svn
properties would indeed have a maintenance burden, but at least the maintenance
needed there would be at the same time and in the same code base as the changes
that necessitated that maintenance.
Perhaps this discussion of deducing the type of property values will sooner or
later, lead to a solution which works well for you. I think it is unlikely
that that code will be in Subversion itself.
Meanwhile, may I suggest that we concentrate on getting basic "proplist" XML
output? I think that would be uncontroversial. If you are willing to change
your patch to do that, it could be accepted soon and would get you a step
closer to what you really want.
- Julian
p.s. There are still warnings:
subversion/clients/cmdline/proplist-cmd.c: In function `print_prop_xml':
subversion/clients/cmdline/proplist-cmd.c:186: warning: implicit declaration of
function `isdigit'
subversion/clients/cmdline/proplist-cmd.c: In function `group_props_xml_rev':
subversion/clients/cmdline/proplist-cmd.c:284: warning: control reaches end of
non-void function
But it's not worth fixing them until we've agreed on a design.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 24 20:07:44 2005