Broken schema specification

Author: Samaresh Panda
Last updated: 02-15-2006

  • Introduction

This document describes the behavior of a broken schema in schema editor. Also, it describes various use cases and scenarios when user tries to open a broken schema in the schema editor and ways to fix the error.

There can be multiple levels of errors. A schema can be considered broken or invalid if:
  1. it is not well-formed
  2. it is not correct, structurally as per schema spec. See http://www.w3.org/TR/xmlschema-1/
  3. it is not correct, in terms of linkage, that is when all references are not resolved properly
Note: a higher level error indicates that all lower level errors have been resolved.

In the following section, we'll discuss various use cases of a broken schema. Not all use cases make sense at all levels. Also the use cases depend on the state transition of the schema, I mean from a valid state to some invalid level or from an invalid level to another invalid level.

  • Use cases

Use case 1: Empty column view
This is the simplest of all. When user tries to open a broken schema, the column view appears as empty. We can have some message in the empty column view, saying, the schema is broken. User needs to fix the error and then come back to the column view.

empty column view

This use case, make perfect sense for a level1 error, that is non-wellformed schemas, considering the fact that we may not be able to build a model with a non-well formed schema.

Use case 2: Partial column view
User gets to see a partial, column view. In other words, we render the column view to a point where we have the correct information from the model and leave the rest, with appropriate message to the user.

Sounds relatively simpler. This approach is good, but it entirely depends on the model. This may be possible for a level2 error.

Use case 3: Entire column view
User gets to see the entire column view, with some error flag error, through all the paths, affected by the error. User should see an informative message when s/he moves the mouse over the icon and on clicking should go to the error in the text view.

This approach is very nice, but again, it entirely depends on the model. This may be possible for a level2 and level3 error.

Use case 4: Read only column view
Another possibility could be to make the column view as a read-only view of the last renderable schema.  We could grey out the column view in this situation, which indicates that the schema got into an invalid state and requires to be fixed.

This approach may have some limitations. Application may need to keep the last valid state information and can be expensive in terms of memory for larger schemas.


  • Transition from one state to another

From Level
To Level
Use Case
level1
level2 UC1 or UC2
level1 level3

leve2
level1
UC4 + (UC1 orUC2)
level2
level3

level3 level1 UC4
level3 level2 UC1 or UC2


Note: Implementation will depend on what we can/cannot get from model.

  • Open Issues

  • All of the approach described above is feasible. Some may be very easy to implement, however may require some changes to the model or the core schema API.
AI: Will have to work with Chris for the model issues and changes.
  • Look at some other IDEs like creator to see what they do in similar situation.
  • Transition from one state to another.

  • Conclusion

It is very common for schema authors to get into an invalid or broken state. And this can be one of the area where we can capitalize as compared to other IDEs. The more informative, friendly,  we are about fixing the error, the more it helps to the end user.



Comments From Todd Fast

Excellent! Comments:

- Barring changes to the model, UC3 (badged errors) could be achieved immediately for broken/unresolved references. Just those would be a big help, though. The badging would require some changes to the nodes, which we are already planning for search.

- As you say, with the current capability we have in the model, UC2 and UC4 (partial and read-only CV) are infeasible. We can discuss further to see what would need to be done to the model, but my feeling is that we won't have the resources to achieve the necessary changes.

- The UI for UC1: I'm not sure if you've coded anything here, but it would perhaps be easiest to just add an error node with a gray message ("Schema is not well-formed. Please correct in text view.") as the root
of the leftmost column. Another alternative would be to use a disabled label with this message centered in the panel (i.e. remove the CV and replace with an error panel).

- Broken projects have a node badge and an action to show/resolve the error information. Should we have the same for broken schemas, and for which error levels (1 is obvious, but what about 2 & 3)?

- Are there other types of schema invalidity? If so, we can lump them into an error level4 that corresponds to general schema invalidity.

- For Java files, when they have been modified by not compiled, they show a little bit pattern next to the class file's node. What about something similar for schemas that have been modified but not checked
for validity? Actually, this begs another question: should validity checking be the equivalent of compilation for a schema, and should it run during a project build?

- What should the Analysis view show for a broken schema?
Depends on what's broken.  The following is the one use case that I've
experienced:  The SIF schemas in Samples do not validate because there
are too many unresolved references, but Find Usages shows what it
can.  In this scenario, AV could check that the schema is not valid
and put out a warning message that the results are incomplete.
   
So you're saying that the AV should still remain functional except in
the case of level1 errors?
 
as long as there's a model, then the query can try to do what it can.  In the example above, the AV doesn't get any feedback from the model that something's wrong, so something would need to be done about that.


Comments From Chris Webster

* In the level description, level 2 I think is both structure and semantics. The J2SE 5 schema compiler validates more than just structure such as UPA violations.

* Level 3 is a special case of level 2. Having a broken reference will  likely result in a level 2 violation. Can't find the definition for a namespace, but we want to highlight this because even though this error will not be highlighted directly by a schema compiler, there is no valid reason that a broken reference is necessary.

* I think it is instructive to look at what is done in other places. If the web.xml file is invalid when you switch to the graphical view, a dialog appears displaying the message and you are forced back to the
text view to correct the problem. The file/project view node is also badged as broken. The navigator view is interesting as it is using incremental parsing and can handle broken state to some degree only the
area where it is broken is incorrect. The navigator does display the syntax error at the appropriate place.

* A form file with an error does not display the form part but does allow source editing. As a side note, it is not clear here how a merge conflict would be resolved as the .form file is hidden.

* Would the partial column view be editable ?

* Currently the model supports level 2 / level 3 editing as these documents are well formed. UC2 is currently realized for these levels.

* It would be nice in the spec to describe the current behavior as a state transition diagram.

* What about considering undo / redo as a way to transition back to a good state. The UC1 could be augmented to allow the user a choice (if possible) for getting back to a good state. Seems like there are several possible choices here: Undo/Redo (this will only work if there is at least one image which was well formed), fix in text view, revert from version control.

* UC4 should be manageable by controlling the Undo / redo size along with the XDM tree mutation model. The model currently reflects the last known good state and thus this use case is more of an issue for the view.

Project Features

About this Project

XML was started in November 2009, is owned by dstrupl, and has 58 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
 
 
Close
loading
Please Confirm
Close