This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
This feature is an architecture requirement. Problem: -------- We have multiple grammar sources like DTD, Schema, ... and we have multiple grammar consumers such as Tree editor and Text editor. Consumers should use unified grammar interface regardless of grammar source. E.g.: ----- GrammarInterface implemented by DTDGrammar and SchemaGrammar TextEditor grammar binding using GrammarInterface TreeEditor grammar binding using GrammarInterface Conclusion: ----------- Let define a GrammarInterface that satisfies queries need by Tree and Text editors. Something like: Iterator<Node> getSuitableElements(Node context) boolean canAdd(Node context, Node newbie) boolean canRemove(Node context, Node die)
Created attachment 2114 [details] GrammarLiasion.java
Created attachment 2115 [details] XML Completion Item
It's a little more complicated than that: 1. The text representation has no information of any node context. 2. Even if such could be made available, the text on most occasions is not well formed to create a context node (besides the overhead of relative reparse). | -> Cursor eg <html> <head | eg <html> <head> | etc 3. The GrammarInterface( should probably be GrammarLiasion) should probably have a skeleton like the attatched file.(GrammarLiasion.java) 4. The actual object that carries the info to the text window should probably have a skeleton like the attatched file. Should not carry any parser dependant code.(XCItem.java) 5. One topic that is important to address here is "How much information should the results carry?". Should they carry all of their declaration or only some part. If all, then how do we go about this. If we use parser handling declarations e.g. XMLElementDeclaration, XMLAttributeDeclaration(o.apache.xerces.v.c) these tend to change over time and are not stable. Should we use ASLS declaration classes, or should we define our own. 6. Preferrably we should retrieve all possible info, so that whosoever needs asmuch can use that much and discard the rest.
Comments on GrammarLiason: We need to add namespace parameter to methods (due to Schema grammars). Or an application must have a set of liasons for every namespace. I am not sure what is better.
Name should certainly be qualified( read javadoc comments). But how to qualify it? Wether to add a new namespace parameter, or use TrAX like {URI}localname scheme or maybe the API should define a QName or take one from somewhere. This is more of an architecture issue.
I have found an application that supports Node context approach. It is completion of XSLT tranformations with knowledge of source grammar and target grammar. To write it a complete context is needed.
Partially implemented -> changed to enhancement.
just curious on the status of this ------- Additional Comments From Petr Kuzel 2001-09-24 02:15 PDT ----- -- I have found an application that supports Node context approach. It is completion of XSLT tranformations with knowledge of source grammar and target grammar. To write it a complete context is needed. thanks dennis
Current status: infractructure is done. There is defined grammar query interface allowing it. Unfortunatelly it is currently utilized only by DTD grammar query. XML Schema query provider and XSLT query provides are planned (no particular roadmap set, yet).
Let these are considered while planning next release.
Target milestone was changed from not determined to TBD
Public contact may be introduced.
Unscheduling from my todo list. New owner is gladly welcome. Meanwhile assigning to abstract issues@xml.netbeans.org owner.