Data processing: presentation processing of document – operator i – Presentation processing of document – Layout
Reexamination Certificate
1998-10-05
2003-05-27
Feild, Joseph H. (Department: 2176)
Data processing: presentation processing of document, operator i
Presentation processing of document
Layout
C715S252000, C715S252000, C707S793000
Reexamination Certificate
active
06569207
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates in general to generating Web content, and in particular, to a method for converting extensible Markup Language (XML) schemas to component models for use in an object-oriented system.
2. Description of Related Art.
Extensible Markup Language (XML) is poised to be the next big revolution for the World Wide Web (WWW). With the realization that the Web is not about just browsing any more, XML has emerged as an enabling technology to carry the Web to the next generation of electronic commerce, Web-based workflow, and integration of databases with Web applications.
XML describes a class of data objects called XML documents and partially describes the behavior of computer programs that process them. XML is a restricted form of SGML, the Standard Generalized Markup Language, defined in ISO 8879. The specification for XML can be found at the URL: http://www.w3.org/TR/REC-xml.
XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure.
An XML schema specifies constraints on the structures and types of elements in an XML document. The basic schema for XML is the DTD (Document Type Definition). Other XML schema definitions are also being developed, such as DCD (Document Content Definition), XSchema, etc. Information concerning DTD and DCD can be found at the URL: http://www.w3.org/.
The main difference between DTD and DCD is that DTD uses a different syntax from XML, while DCD specifies an XML schema language in XML itself. (XSchema is similar to DCD in this respect). In spite of the differences in the syntax, the goals and constraint semantics for all these XML schema languages are the same. Their commonality is that they all describe XML Schema. This means that they assume the common XML structure, and provide a description language to say how these elements are laid out and are related to each other.
There are about five basic constraints that the XML schema languages describe:
1. The attributes that an element should/may contain:
a. the types of the attribute values (mainly string types), and
b. the mandatory or optional nature of occurrences of these attributes.
2. The type and the order in which elements can be contained inside another element (the content model of the element):
a. the sub-element should of a certain name or type or that a sub-element could be of any type,
b. a regular expression system to express how these elements occur, wherein this regular expression system can be expressed by the following operators:
i. |:A|B (either element of type A or of type B can occur),
ii. ,:A, B (element of type B follows one of type A),
iii. *:A* (zero or more occurrence of element of type A),
iv. +:A+ (one or more occurrence of element of type A),
v. ?:A? (zero or one occurrence of element of type A),
vi. ( ):( . . . , ) (grouping of expressions in this system).
An EBNF (Extended Backus-Naur Form) for this regular expression system can be expressed as below:
re=>A
|re|re
|re, re
|re*
|re+
|re?
|(re)
|ANY
Note that this system includes some convenience operators. For example, A+ is the same as A, A*.
A software module called an XML processor is used to read XML documents and provide access to their content and structure. It is assumed that an XML processor is doing its work on behalf of another module, called the application. The XML specification located at the URL noted above describes the required behavior of an XML processor in terms of how it must read XML data and the information it must provide to the application.
In a typical application that uses XML for a particular specification, there would be a DTD that specifies the XML schema and one or more XML documents that satisfy that schema. The application would typically convert the XML document into an object. The application programmer would typically write several lines of code to read in the XML document based upon the schema, to get and set elements and properties based upon the schema, and to notify other parts of the application when an element in the document changes.
It can be seen, then, that there is a direct correspondence between XML schemas and Java classes, as well as XML documents and Java objects. However, when application programmer manually writes this programming, it is painstaking, and error-prone. Thus, there is a need in the art for a well-tested system that can automatically generate this programming.
Of course, automatic program generation is known in the art. For example, in U.S. Pat. No. 4,949,253, Chigira and Yokoyama describe an automatic program generation method and apparatus in a computer program development support system having an input unit for inputting input information relating to data declaration and manner of use of data, a memory unit for storing a plurality of program part prototypes, each including modifyable information and a processing unit for generating a program part from a program part prototype, wherein the input information is analyzed, one of the program part prototypes stored in the memory unit is selected in accordance with the analysis of the input information, and the selected program part prototype is substituted in accordance with the analysis of the input information to generate a program.
In another example, in U.S. Pat. No. 5,269,014, Ogino describes an an automatic programming system that seeks to maximize the automation of software development. This automatic programming system includes capability to trade-off program structure so as to optimize the structure to fulfill requested software specification requirements. The system also includes an ability to perform failure mode and effect analysis and design review. The design operation and testing operations are directly coupled to each other so that the design data may be utilized effectively during testing
In yet another example, in the publication by Budinsky, Finnie, Vlissides, entitled “Automatic code generation from design patterns”, IBM Systems Journal Vol. 35, No. 2- 1996, the authors describe a method to generate code from design patterns.
In all of these systems, the user has to explicitly write specifications or prescriptions for the purpose of code generation. There is no way to automatically extract information for component code generation. Specifically, there is a need for a system that can generate Java classes using XML schemas and then instantiate Java objects using XML documents.
SUMMARY OF THE INVENTION
To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a system for automatically generating class specifications from XML schemas and then automatically instantiating objects from those class specifications using data contained in XML documents.
REFERENCES:
patent: 4949253 (1990-08-01), Chigira et al.
patent: 5269014 (1993-12-01), Ogino
patent: 5491628 (1996-02-01), Wakayama et al.
patent: 5530863 (1996-06-01), Hino
patent: 5548508 (1996-08-01), Nagami
patent: 5608904 (1997-03-01), Chaudhuri et al.
patent: 5629846 (1997-05-01), Crapo
patent: 5659729 (1997-08-01), Nielsen
patent: 5715453 (1998-02-01), Stewart
patent: 5802529 (1998-09-01), Nakatsuyama et al.
patent: 5878411 (1999-03-01), Burroughs et al.
patent: 5915259 (1999-06-01), Murata
patent: 5920879 (1999-07-01), Kyojima et al.
patent: 5940075 (1999-08-01), Mutschler, III et al.
patent: 6014680 (2000-01-01), Sato et al.
patent: 6055522 (2000-04-01), Krishna et al.
patent: 6055526 (2000-04-01), Ambroziak
patent: 6226642 (2000-05-01), Beranek et al.
patent: 6073143 (2000-06
Feild Joseph H.
Gates & Cooper LLP
LandOfFree
Converting schemas to component models does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Converting schemas to component models, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Converting schemas to component models will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3089372