Re: [unrev-II] patching xml based source

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Tue Feb 15 2000 - 15:27:42 PST


From: Eric Armstrong <eric.armstrong@eng.sun.com>

Jeff Miller wrote:
>
> Eric, you talked about using xml to develop source code, how to
> translate
> it to text in the early stages to use the current compilers. One thing
> that you din't mention is how to handle patches. So how do you patch
> with
> xml based source code? I'd image replace node/change node operations.
> What about patches that get submitted in the normal text style?
>
Not sure I follow you.
In my experience, "patches" applies to binary fixes. You modify
the binary code with a "patch" that substitutes new opcodes for
old ones.

On the source code side, I see editing operations, monitored by
version-control and differencing applications, which is unchanged.
You just have a different editor.

Ideally, everyone would use the same XML system for storage.
The versioning and differencing can then take place within that
system. That requires a major commit by a central decision-maker,
however, which can be hard to accomplish.

The second strategy is to encourage "guerilla" incursions, by
filtering the XML to plain text. You operate on a file by
checking it out of the plain text version repository and parsing
it into XML structures. You then do your edits, filter back to
plain text, and put it back in the repository.

In the source code world, then, you are either working with
an all-XML repository, in which case you get diffs that result
from others' edits when you update your copy (those diffs might
be called "patches" in some areas, although I've never heard that
myself) -- or else you are working with a plain-text repository,
in which case you the document, the whole document, and nothing
but the document: in other words, the whole source file.

That strategy lets one person use the environment, interact with
the standard environment, and gradually "sell" coworkers and
managers on the process, by virtue of productivity, etc.

Several problems remain to be worked out before that strategy
is viable, however. Among them:
  * XML-links to external explanations won't be traversable
    by plain text users. So the XML links will have to be
    encoded as comments in the source file. Will that cause
    any technical problems or barriers to acceptance?

  * In XML, you can comment out a block of code quite easily.
    But when you filter that to plain text, how do you do
    so in a way that makes it possible to recover the original
    structure. (Turns out to be quite tricky.)

  * The plain-text write-up of a comment could contain lists,
    HTML structures, or (for normal comments) various "lists"
    that start with a space or two and an asterisk, for example.
    How do you parse plain text comments accurately so as to
    create the proper XML structure? Or do you punt on the whole
    issue and store them as CDATA?

    [The best strategy might be to store normal block comments
     as uninterpreted CDATA, and forget about parsing them.
     JavaDoc comments, on the other hand, can be put into
     XML structures by parsing the HTML -- which means that
     a Java-to-XML filter needs an HTML parser as well as a
     language parser...]

Did I stumble across an answer to your question, anywhere in there?

--------------------------- ONElist Sponsor ----------------------------

FREE ADVICE FROM REAL PEOPLE! Xpertsite has thousands of experts who
are willing to answer your questions for FREE. Go to Xpertsite today
and put your mind to rest.
<a href=" http://clickme.onelist.com/ad/XpersiteCPC ">Click Here</a>

------------------------------------------------------------------------

Community email addresses:
  Post message: unrev-II@onelist.com
  Subscribe: unrev-II-subscribe@onelist.com
  Unsubscribe: unrev-II-unsubscribe@onelist.com
  List owner: unrev-II-owner@onelist.com

Shortcut URL to this page:
  http://www.onelist.com/community/unrev-II



This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:47 PDT