Patent Grant
7904809
XML documents are increasingly being used to perform a variety of different operations in a number of different contexts. For example, enterprise management systems may provide management packs or other maintenance documents in XML form. In addition, human authors may create XML documents that contain test cases for some software or system under test.
As XML documents continue to proliferate, these documents may represent abstract information having increased richness and complexity. These documents may express multiple relationships between elements within the same document, as well as between elements within two or more different documents. Many of these constraints are not expressible using standard XML validation techniques. Edits and revisions to such documents may consume considerable time. Typically, these documents are submitted to a post-edit validation process after editing is completed. However, if this validation process identifies any errors, the time spent editing the document may be effectively wasted. This issue may become especially acute as the complexity of the document contents increases.
Tools and techniques for dynamically validating editors are described herein. The tools may provide machine-readable storage media containing machine-readable instructions for receiving indications of user edits to a portion of a document, and for determining whether a customized editor is available for the edited portion of the document. The tools may also provide systems that include at least the dynamically validating editor.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The term “tools,” for instance, may refer to system(s), method(s), computer-readable instructions, and/or technique(s) as permitted by the context above and throughout the document.
Tools related to dynamically validating editors are described in connection with the following drawing figures. The same numbers are used throughout the disclosure and figures to reference like components and features. The first digit in a reference number indicates the drawing figure in which that reference number is introduced.
Overview
The following document describes tools capable of performing and/or supporting many techniques and processes. The following discussion describes exemplary ways in which the tools provide for dynamically validating editors. This discussion also describes other techniques and/or processes that the tools may perform.
The systems 100 may enable one or more authors 106 to create, revise, or otherwise edit documents in, for example, the Extensible Markup Language (XML).
Turning to the workstations and servers, the workstation may communicate remotely with the server, or the workstations may be standalone systems. Workstations and/or servers may be computer-based systems that include one or more processors, denoted at 112. These processors may also be categorized or characterized as having a given type or architecture, but may or may not have the same type or architecture.
The workstations and/or servers may also include one or more instances of machine-readable or computer-readable storage media, denoted generally at 114. The processor 112 may communicate with the computer-readable media 114, and other components or sub-systems of the workstations and/or servers, via one or more busses 116. These busses 116 may be of any suitable width, and may comply with any convenient bus architecture.
The computer-readable media 114 may contain instructions that, when executed by the processor 112, perform any of the tools or related functions that are described herein as being performed by the workstations and/or servers. The processor may access and/or execute the instructions embedded or encoded onto the computer-readable media, and/or may access data stored in the computer-readable media. Additionally, it is noted that the computer-readable storage media, and any software stored thereon, may reside on hardware other than that shown in
Turning in more detail to the computer-readable media 114, it may include one or more instances of a management pack authoring console application 118. The management pack authoring console 116 in turn may include at least a dynamic validating editor 120, which represents a collection of software instructions that, when loaded into the processor and executed, may enable the workstation and/or server to perform any of the tools described herein.
In overview, the dynamic validating editor may enable the author to create or edit one or more XML documents (e.g., 108). The workstations and/or servers may provide a suitable user interface 122, though which the author may interact with the workstations and/or servers in working with the XML documents. More specifically, based at least on where in the XML document the author is working and what type of data the author is working with, the validating editor may dynamically select UI elements to present to the author. Thus, the validating editor may vary the UI elements presented to the author, depending on the context within which the author is working in one or more of the XML documents.
Having described the systems and/or operating environments 100 in which dynamically validating editors may perform in
As shown in
The tree 202 represents a model of the dynamic relations between the XML nodes 204.
The XML document 108 may be associated with an XML Schema Definition (XSD) file, denoted at 208. The XSD file may be used to statically validate the XML instance document as the author edits the document. Without limiting possible implementations, static validation may refer XSD validation that has no control flow mechanism and no built in event handling mechanism. This, in turn, means that an instance node value may not depend logically on the value of other instance nodes. Also, this means that when a given node changes, nodes dependent on the changed node have no way to change which parts of the XSD schema now apply to the dependent node's value validation.
The XSD file as described herein may extend the static validation capability of XSD by adding general purpose XSD <xs:appinfo> nodes under the <xs:annotation> node. These appinfo nodes describe location of the code extensions to use to edit those elements and and/or use to perform dynamic validation of those edits. This code can be called from the editor itself, or from a totally separate dynamically-linked library (dll).
The model described herein may assign custom editors to the XSD file, and may associate these editors with respective nodes in the XML document.
As detailed further below, these custom editors 210 have detailed knowledge of the intra-node dynamics of the XML document. Put differently, the XSD file describes the structural relationships between XML nodes, as well as providing data types for the nodes.
Using a suitable attribute (e.g., the vs:editor attribute), the XSD file can notify the model-based editor (e.g., 120) of the strongly-typed editor for a given node being edited by the author. For example,
More particularly, the editor 120 may consumes the value of the attribute (e.g., vs:editor), and may decide at design time precisely which UI element (e.g., 128) to expose to the author. This choice can be based on the current state of the XML document. In other words, the model-based editor 120 can treat an XML file like a state machine, branching control of the editing surface based on the current state of the “machine.” In this analogy, the nodes of the XML document correspond to the states of this machine.
As an example of the foregoing, assume that the author is editing a node of the XML file to define some “string” value. In this example, the editor 120 may sense whether the string value of the node can be an arbitrary string typed in a text box, or whether the string value is to be taken from a dropdown list of predefined, available strings, with this list being populated with the names of classes pulled from a .dll file or pulled from another file (e.g., a Management Pack).
The following example shows how the tools described herein may take a declaration of a cls attribute defined in a varmap schema, and decide whether to provide a custom dropdown control to edit the cls attribute's instance value, or to leave the field as a text box to be filled with arbitrary text. The choice between these options may depend on the current state of the XML document. For example, this choice may depend on the values of the assembly attribute and the current variable's mode attribute. The model of the interplay of these three fields is described below.
As the discussion proceeds below, the description includes various samples of code segments as an aid to understanding the concepts provided as part of the tools. However, it is noted that these segments of code are illustrative in nature, and do not limit possible implementations of the description herein. For example, the names of various variables, classes, methods, and functions are provided only for ease of reference, and implementations of the description may use different names without departing from the scope and spirit of the description herein. Additionally, it is noted that various alterations or modifications of these code segments are possible, also without departing from the scope and spirit of the description herein.
Continuing this example, a sample XSD declaration is now provided, calling attention to the type attribute and vs:editor values. In this example, both values are used to establish context for the editor.
Here are example varmap.xsd declarations for the two user-defined types used by a ReflectionEditor:
Referring to
Referring to the example, but non-limiting code listing below, the edit process may begin with a reference to the editor 120, which sets the SchemaType of the edited node and returns an instance of a custom editor, if possible, as represented at decision block 306. If a custom editor is available, as indicated by the “Yes” branch from block 306, the editor may obtain a custom editor for the node, as indicated at block 308. After obtaining an instance of the custom editor, BeginEdit( ) populates that editor based on the XSD type from the schema, as indicated at block 310. That is, the editor 120 may set its SchemaType property to the simpleType named “reflectedClassType”. The editor 120 may determine that the ListBox control may obtain items taken from the list of classes in the varmap's test assembly, as shown in the SchemaType property listing and as represented at block 312.
Block 314 represents presenting the custom editor to the user, and block 316 represents receiving a response from the user to the custom editor. Continuing the example above, if the user is editing a given node to have a “string” value, a schema governing the XML file may permit filling the string with different types of values. For example, the schema may specify that the string is to be filled with an arbitrary string. Alternatively, the schema may stipulate that the string value be populated from a set of predefined choices specified by an enum in the schema. Thus, the editor as presented to the user may permit the user to enter an arbitrary string, or may permit the user only to select from one of the predefined alternatives from a dropdown list. In this manner, the customized editor may implement any restrictions specified by the schema that are applicable to the node currently being edited. In addition, the customized editor may implement restrictions that are not specified by the schema, or that are not expressible in schema. For example, the customized editor may show choices that are based on reflection of classes in a given assembly.
Additionally, the customized editor may validate any inputs or edits to the revised document when the user or author provides these inputs or edits. If some input is invalidated, the customized editor may explain to the user any validity, and may recommend corrective action, substantially in real time with the invalidated inputs. In this manner, the dynamically validating editor may enable the user to save time when editing the document, as compared to completing all edits, and then submitting the edited document in batch to a post-edit validation process.
As indicated in the code segment below, specifically the portion beginning with the line “if (this.editor!=null) . . . ”, the currentEditor performs the actual edits in a UI provided by the editor. Referring back to decision block 306, the currentEditor may obtain a reference from the instantiated custom editor, as indicated by the Yes branch from block 306 to block 308. However, if no custom editor exists for a given node, the currentEditor may obtain a reference from the default textbox control, as indicated by the No branch from block 306 to block 318.
The Editor constructor may query the schema for the vs:editor value, using that string to instantiate and return an instance of the (named) class that implements the IXmlEditor interface, if possible. Note this is a case where the editor 120 is context sensitive. Also, the comments below indicate the dynamic nature of editing the cls attribute.
The editor 120 may use .Net Reflection to invoke the named constructor to create a new instance of the named .NET class, in this example, the Socrates.ReflectionEditor constructor.
Since the Socrates.ReflectionEditor subclasses the SocratesEditor, the SocratesEditor implements the IXmlEditor interface by adding a GetDataSourceAppInfo method, to which the discussion returns below.
The Socrates.ReflectionEditor overrides the SchemaType property and uses the information to dynamically calculate the list of items to populate the in the listbox which is returned as the editor 120.
In this example, if the SchemaType is reflectedMethodType, the editor 120 may iterate methods only for the specified class name.
Sometimes the value of an element or attribute is context sensitive, where context is ordinal. The set, lvl, and vid attributes in the varmap var element are an example of this. If a var is inserted, moved, copied or deleted, then attribute values of the new var or vars before and after the modified/new var may be updated. The model-based editor 120 constructed as described herein senses that the new attribute values are to be updated. In this case, a specific dynamically validating editor may not into play, but instead a dynamically valid edit. The model-based editing infrastructure described herein may handle automatic and/or discretionary edits.
In the next example, the description discusses how a new var gets its default values for its set, lvl, vid, and cid attributes.
Referring to the code segment below, an OnNodeInserted event handler is called after a node edit is complete. New elements are created using the CodeSnippet class that uses the Schema Object Model to generate any suitable attributes and elements from the instance document's XSD file (e.g., 208). In these cases, the editor 120 may have already created a new var node, but that new node may have no attributes. The OnNodeInserted( ) event generates suitable attributes for vars (there are no required elements for vars), adds the attributes to the new node, then sets the attribute node of the current var to its (context-sensitive) default value.
SetDefaultValue( ) first sets the IntellisenseProvider's contextNode to the new node, and this triggers a validation of the new context. First, a validation utility (e.g., the Socrates editor described herein) validates the element using the schema.
Next, the editor 120 may override OnContextChange and perform custom validation using its model of a SocratesTreeNode.
After validating the new node, the editor obtains the new attribute's default value. If the XSD file generates the XML for the new node, it may be redundant to validate this XML again. Since attributes like set, lvl, and vid depend on the value of those attributes in the var preceding the current one, GetDefaultValue( ) obtains a reference to the var's previous sibling, referred to herein as the new var's “uncle” node. The current set attribute is in the current var node's context. The set's uncle var node is the sibling of the set's parent, ergo, uncle.
The default value for set is the uncle var's set attribute value. The default value of lvl is “0”, unless the uncle node is a var, in which case that lvl is reused as a default. The vid is an ordinal value, so 1 is added to the uncle's vid, assuming uncle is a var with the same set and lvl.
Regarding the other var attributes, their default values are obtained from enums (if the attribute is based on an enum type in the schema) or from the base class.
Two other types of editors are the IDRefEditor and the AutoGenEditor. The AutoGenEditor may operate as follows: when editing an extant attribute whose vs:editor is set to Socrates.AutoGenEditor, the AutoGenEditor may calls the same GetDefaultValue( ) method that is used for new attributes.
The IDRefEditor may operate by calling the method with which the editor 120 extended the IXmlEditor interface. The editor 120 may support model-based testing. When editing a preref (or postref) attribute of the fnc childnode of the var element, the IDRefEditor can gather data from a states element to ensure only valid pre and post conditions are assigned to an fnc element. If the varmap does not contain any state's elements, the IDRefEditor has nothing to display, and so the editor 120 may so warn the author and advises ways to resolve the issue.
Model-based editing as described implement “models” of the interrelationship between elements programmatically. However, further augmentations to the XSD file may enable it to store the models that would otherwise be expressed in code. Further, by referring to the XSD file, the editor 120 may divine these models from the schema at runtime. These augmentations may keep the models close to the XSD, and may make the models portable, such that the models are used only when the correct XSD namespace is in scope.
Although the systems and methods have been described in language specific to structural features and/or methodological acts, it is to be understood that the system and method defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed system and method.
In addition, regarding certain data and process flow diagrams described and illustrated herein, it is noted that the processes and sub-processes depicted therein may be performed in orders other than those illustrated without departing from the spirit and scope of the description herein. Also, while these data and process flows are described in connection with certain components herein, it is noted that these data and process flows could be performed with other components without departing from the spirit and scope of the description herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6604099 | Chung et al. | Aug 2003 | B1 |
| 6910040 | Emmick et al. | Jun 2005 | B2 |
| 6950985 | Lee | Sep 2005 | B2 |
| 6988025 | Ransom et al. | Jan 2006 | B2 |
| 7039859 | Sundaresan | May 2006 | B1 |
| 7058558 | Reichenthal | Jun 2006 | B2 |
| 7096224 | Murthy et al. | Aug 2006 | B2 |
| 7155670 | Takizawa et al. | Dec 2006 | B2 |
| 7225425 | Kompalli et al. | May 2007 | B2 |
| 20020147745 | Houben et al. | Oct 2002 | A1 |
| 20020184188 | Mandyam et al. | Dec 2002 | A1 |
| 20030046317 | Cseri et al. | Mar 2003 | A1 |
| 20030069887 | Lucovsky et al. | Apr 2003 | A1 |
| 20040177321 | Brown et al. | Sep 2004 | A1 |
| 20050102612 | Allan et al. | May 2005 | A1 |
| 20050273707 | Chu et al. | Dec 2005 | A1 |
| 20060101038 | Gabriel et al. | May 2006 | A1 |
| 20060143562 | Seurig et al. | Jun 2006 | A1 |
| 20060150085 | Davis et al. | Jul 2006 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20090006947 A1 | Jan 2009 | US |
