On Wed, 4 May 2005, C. Michael Pilato wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
>
> > On Wed, 4 May 2005, [utf-8] Ã^Xyvind A. Holm wrote:
> >
> > > On 2005-05-04 08:24:09 Peter N. Lundblad wrote:
> > > > On Wed, 4 May 2005, [utf-8] ?^Xyvind A. Holm wrote:
> > > > > On 2005-05-02 05:09:09 alexander@collab.net wrote:
> > > > > > Version: 2, Patch to add XML output for 'svn blame'
> > > > > [...]
> > > > > - And the actual text line with it's own element from the file is
> > > > > missing in the XML.
> > > >
> > > > That's deliberate (see the feedback to the first version of the
> > > > patch). In short, we don't know the encodig of the file content, so we
> > > > can't include it in XML (which has to be UTF8, or some or some other
> > > > encoding, but it has to be consistent.) It is easy to get at the
> > > > content with svn cat.
> > >
> > > Yes, that's a good reason not to include the actual line text. But what
> > > about including the actual line number instead? XML suggestion:
> > >
> > With an entry element for each line, I don't see a point in showing that
> > the computer can count:-) Remember that this isn't for humans.
>
> Isn't it kinda naughty to assume that order matters in XML output? I
> mean, a text process should be able to reorder the <entry> subtrees
> with no detriment to an XML parser.
>
I disagree. Maybe you're confusing attributes and elements in this
respect. The order of attributes on an element is insignificant. The order
of elements is not. (Or do you want to read the svn book with order
insignificant:-)
Ofcourse, we might *want* to specify that order is to be treated as
insignificant in a particular context. Then any processor must be able to
cope with entries in any order, which might increase the burden on the
processing application.
> Secondly, if we aren't showing the line data, is it
desirable to have
> entries cover more than one line of data at a time? Line ranges, that
> is, like so:
>
> <?xml version="1.0" encoding="utf-8"?>
> <blame>
> <target
> path=".bashrc">
> <entry
> revision="32">
> <author>sunny</author>
> <date>1999-07-02T16:36:59.000000Z</date>
> <startline>1</startline>
> <endline>54</endline>
> </entry>
>
I wouldn't think it is worth the extra work.
> Finally, where is the line drawn on what pieces of data are
> represented at tag CDATA versus attribute values? I always assumed
> that one of two trains of extremist thought might be prevalent:
>
This was discussed some months ago. I think SGML experts have tried to
draw the line for decades now.
> - Never use attributes, period, or
>
More verbose, decreases readability somewhat. You need to specify if order
is significant.
> - Use attributes for all data that doesn't have heirachy (which,
> for our current 'svn blame' output, includes revision, author,
> date, and pretty much every other thing in the <entry>
>
My rule of thumb is something like that: use attributes for simple dta
types that will not need to become structured in the future. But in this
case, I think we should be consistent with the list.dtd:
<!ELEMENT entry (commit?)>
<!ELEMENT commit (author?, date?)> <!-- * -->
<!ATTLIST commit revision CDATA #REQUIRED>
*) Not exactly consistent, since author and date or not optional in
list.dtd, but I think that's a bug.
As I said, this discussion has some history; it reflects that attributes
are essentially syntactic sugar (except for ID/IDREF and some arcain
datatypes).
More about the DTD tonight.
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 4 11:13:55 2005