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.

Bug 14296 - Unified Grammars Approach
Summary: Unified Grammars Approach
Status: NEW
Alias: None
Product: xml
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@xml
Keywords: API
Depends on:
Blocks: 21098 28602 30096 20421 20532
  Show dependency tree
Reported: 2001-08-09 12:00 UTC by _ pkuzel
Modified: 2007-09-25 01:31 UTC (History)
0 users

See Also:
Exception Reporter:

Attachments (2.20 KB, text/plain)
2001-08-09 17:08 UTC, _ srandhawa
XML Completion Item (1.45 KB, text/plain)
2001-08-09 17:13 UTC, _ srandhawa

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2001-08-09 12:00:48 UTC
This feature is an architecture requirement. 


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.


GrammarInterface implemented by DTDGrammar and SchemaGrammar
TextEditor grammar binding using GrammarInterface
TreeEditor grammar binding using GrammarInterface

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)
Comment 1 _ srandhawa 2001-08-09 17:08:40 UTC
Created attachment 2114 [details]
Comment 2 _ srandhawa 2001-08-09 17:13:16 UTC
Created attachment 2115 [details]
XML Completion Item
Comment 3 _ srandhawa 2001-08-09 17:14:58 UTC
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.(

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.(

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.
Comment 4 _ pkuzel 2001-08-10 14:36:50 UTC
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.

Comment 5 _ srandhawa 2001-08-15 14:13:06 UTC
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.
Comment 6 _ pkuzel 2001-09-24 10:15:07 UTC
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.
Comment 7 _ lkramolis 2001-12-04 18:03:08 UTC
Partially implemented -> changed to enhancement.
Comment 8 Dennis Daniels 2002-02-10 11:44:41 UTC
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.

Comment 9 _ pkuzel 2002-02-11 09:11:16 UTC
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).
Comment 10 _ pkuzel 2002-06-03 12:26:23 UTC
Let these are considered while planning next release.
Comment 11 Marek Grummich 2002-07-19 16:46:47 UTC
Target milestone was changed from not determined to TBD
Comment 12 _ pkuzel 2002-08-13 21:16:07 UTC
Public contact may be introduced.
Comment 13 _ pkuzel 2003-09-03 11:10:38 UTC
Unscheduling from my todo list. New owner is gladly welcome. Meanwhile assigning
to abstract owner.