señior ¿tyrtle? wrote:
> Index: subversion/clients/cmdline/dtd/proplist.dtd
> ===================================================================
> +<!-- XML DTD for Subversion command-line client output. -->
> +
> +<!-- For "svn proplist" -->
> +<!ELEMENT propertylist (list | target)>
> +<!ELEMENT list (target*)> <!-- list is allowed to be empty -->
> +<!ELEMENT target (entry*)> <!-- allowed to be empty (no properties) -->
> +<!ATTLIST target path CDATA #REQUIRED> <!-- must have a local path or URL -->
> +<!ELEMENT entry (integer | real | string | true | false | data | date)>
> +<!ATTLIST entry name CDATA #REQUIRED> <!-- entry must have a name -->
> +
> +<!ELEMENT string (#PCDATA)> <!-- string -->
> +<!ELEMENT integer (#PCDATA)> <!-- integer number -->
> +<!ELEMENT real (#PCDATA)> <!-- floating point number -->
> +<!ELEMENT true (#PCDATA)> <!-- boolean <true/> -->
> +<!ELEMENT false (#PCDATA)> <!-- boolean <false/> -->
> +<!ELEMENT date (#PCDATA)> <!-- a date in ISO format -->
> +<!ELEMENT data (#PCDATA)> <!-- property value encoded in base-64 -->
> \ No newline at end of file
Like Peter said, it's helpful to treat the DTD as a partial specification of
the feature, so that's where I'll start.
I don't see the point of making a special case for when the number of targets
is exactly one: it just adds complexity. Unless you had a special reason, omit
the "list" element and make "propertylist" have content "(target*)".
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. If your goal is to have
the known "svn:" properties parsed and presented specially, then the output
should indicate this by having elements that correspond to the particular
parsed properties, something like this:
<!-- An "svn:" property is always parsed into an "svnprop" element;
other properties are put in a "string" if possible, else "base64". -->
<!ELEMENT entry (svnprop | string | base64)>
<!ATTLIST entry name CDATA #REQUIRED>
<!ELEMENT svnprop (svnlog | svndate | svnauthor |
svnexecutable | svnignore | ...)>
<!ELEMENT svnlog (#PCDATA)> <!-- svn:log: a string -->
<!ELEMENT svndate (#PCDATA)> <!-- svn:date: a date in ISO format -->
<!ELEMENT svnexecutable EMPTY> <!-- svn:executable: present or absent -->
<!ELEMENT svnignore (svnignoreentry+)> <!-- svn:ignore -->
<!ELEMENT svnignoreentry (#PCDATA)> <!-- a filename pattern -->
...
<!ELEMENT string (#PCDATA)> <!-- property value as a string -->
<!ELEMENT base64 (#PCDATA)> <!-- property value encoded in base-64 -->
That, however, would be something that the normal "svn proplist" to the console
does not do (although it wouldn't necessarily make much difference to the
visible result if it did). I'm not sure whether this is appropriate. Other
people's thoughts, please?
- Julian
p.s. Though I'm not yet reviewing the code, I compiled it and there were some
warnings:
> subversion/clients/cmdline/proplist-cmd.c: In function `print_prop_xml':
> subversion/clients/cmdline/proplist-cmd.c:191: warning: implicit declaration of function `lround'
> subversion/clients/cmdline/proplist-cmd.c: In function `group_props_xml':
> subversion/clients/cmdline/proplist-cmd.c:297: warning: control reaches end of non-void function
> subversion/clients/cmdline/proplist-cmd.c: In function `begin_xml_proplist':
> subversion/clients/cmdline/proplist-cmd.c:326: warning: control reaches end of non-void function
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 24 14:32:20 2005