for information about XES schema see these pages.
Comment
Allows comments to be inserted anywhere in program
for information about XES schema see these pages.
Allows comments to be inserted anywhere in program
<xs:complexType name="commentType" mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:any processContents="lax"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
These are possible changes as described here.
How do you think comments should be handled in XES? I think it is very important
that the original source code can be reconstructed fully without altering comments.
The coding and decoding process will alter whitespace and a possible small change
to the position of the comment, but there should be no more.
To do this any node type can have a comment under it, I guess this makes the
DTD or schema more complicated, would it be better to move comments out from
some node types?
The issues are explained here in terms of encoding Java but there are similar
constructs in other languages and as far as possible the encoding should be
language independent.
Current Method
--------------
Currently I use the method from the java parser at the sun site:
<"/**" ~["/"]> { input_stream.backup(1); } :
IN_FORMAL_COMMENT
<IN_FORMAL_COMMENT>
SPECIAL_TOKEN :
{
<FORMAL_COMMENT: "*/" > : DEFAULT
Then everywhere a token is read in the file a checkForComment method is called
as follows:
t = "package" {checkForComment(t);}
This checkForComment method extracts the special token, puts the text in a nodeComment
and then pushes the nodeComment so it will appear in the right place in the
tree.
Required Method
---------------
What I thought is that, if the formal comment occurs just before a method, class
or parameter definition, then the javaDoc information is parsed to extract metadata
to be stored under the method, class or parameter definition nodes. For example
given the following comment before a comment definition:
/**
* Returns an Image object that can then be painted on the screen.
* @param url an absolute URL giving the base location of the image
* name the location of the image, relative to the url argument
* @return the image at the specified URL
* @see Image
*/
I suggest we create nodeReturn and nodeSee nodes and put them under the method
definition node (along with a nodeComment to hold the residual unstructured
string).
Then nodeParam nodes need to be created for url and name and put under the appropriate
parameter nodes which is itself under the method definition node.
I think it would also be good to consider how this can be combined with metadata
from the new Java 5 Annotations syntax.
This mixture of structured and unstructured information seems very difficult
to me, so I would very much appreciate any help,
// single line type
/* multi line type */
// single line type
/* multi line type */
metadata block |
|
see also: |
|
Correspondence about this page |
This site may have errors. Don't use for critical systems.
Copyright (c) 1998-2023 Martin John Baker - All rights reserved - privacy policy.