corner imagecorner image FeaturesPluginsDocs & SupportCommunityPartners

XML Modules: API | Catalog | Core | CSS | TAX | Text Editor | Tools | Tree Editor | XSL
XML Project: User | Dev | Links | Features | UML | FAQ | Issues

XML Document Model Requirements

Status: draft #2 | Changes: available in CVS | Issue: #26478

This document describes expectations and requirements for an XML Model. Defined requirements reflect specified problems in general XML Document Model document.
Content:

1. Introduction

XML Model represents XML document (including DTD and parsed external entity) [XML] in memory. Built Model instance allows document navigation and manipulation. The Model can be also stored back to an XML format document.

This document collects requirements and open issues about XML Model suitable for NetBeans. Tools (including NetBeans) have special requirements, because such Model must be mainly structure oriented, i.e. it must deeply describe appropriate XML document.

2. Requirements

  • [R-01] - XML Data API

    This is a basic requirement. An XML document describes a hierarchic data, i.e. one root element; an element can contain textual data or other elements; each element can contain attributes (name and assigned value); an element or an attribute can be associated with a namespace. This API will use who wants just to manipulate with data described by XML document. The Model will always describe well-formed document.

    • [P-05] There is no support for working with external entities
    • [I-02] What is a relation to the XInclude?
    • [I-06] What is a relation to the DOM?
    • [I-09] How to transparently work with entity references?
    • [I-10] How should be handled default values?
  • [R-02] - XML Structure API

    This API extends XML Data API by all syntactic items described in the [XML] specification, including comments, processing instructions, entity references and all DTD declarations.

    • [P-01] Changes made in Explorer (Model) lose part of document
    • [P-05] There is no support for working with external entities
    • [P-06] DTD structure is still read-only in Explorer view
    • [E-04] Improve support for manipulation with external entities
    • [I-01] What is a relation to the XML Information Set?
    • [I-03] Should the Model always hold well-formed document?
    • [I-04] What is a relation to an XML text editing?
    • [I-05] How should be modeled indentation?
    • [I-06] What is a relation to the DOM?
    • [I-08] How deep should be a support for parameter entities?
    • [I-09] How to transparently work with entity references?
    • [I-10] How should be handled default values?
  • [R-03] - Event API

    Fire event on an appropriate item and also bubble this event to the Model root. It could be nice to be able to switch event firing off, or postpone it for a while, e.g. during merging Model instances.

    • [P-01] Changes made in Explorer (Model) lose part of document
    • [P-04] Changes made in Explorer (Model) reformat document indentation
    • [I-06] What is a relation to the DOM?
  • [R-04] - Input/Output API

    Build instance of Model from an input source (involve position support) and serialize the Model to an XML output result.

    • [I-06] What is a relation to the DOM?
  • [R-05] - XML Grammar API

    An abstract API to transparently query associated grammar to a XML document, e.g. DTD, XML Schema, RELAX, etc. This API will be used by code completion in source editor as well as in generic tree editor.

    • [E-04] Improve support for manipulation with external entities
    • [I-04] What is a relation to an XML text editing?
    • [I-06] What is a relation to the DOM?
  • [R-06] - Model Lock API

    It is necessary to be able to lock a Model instance, then do not allow modification operations in some cases, e.g. merge new Model instance into old one.

    • [E-03] Allow locking of Model to prevent concurrent modification
  • [R-07] - Thread Safe Model

    The Model should be ready for modification from different threads at same time.

    • [E-03] Allow locking of Model to prevent concurrent modification

    Resolution: Clients should be responsible for doing so using Model Lock API, if they might access it from >1 thread. (Jesse Glick's suggestion at dev@xml.netbeans.org.)

  • [R-08] - Merge Model Support

    Original Model instance updates data according to new Model instance. It means that where possible, original Model items are preserved; new items are created; and old Model parts are removed. I.e. new Model instance is used just to bring actual data to originally built Model instance.

    • [P-03] Changes made in Source Editor collapses nodes in Explorer
  • [R-09] - Position Support

    To provide full two-way editing it is necessary to know from which position in original document is the part changed in a Model instance. With a position support just affected part of textual representation can be replaced.

    • [P-01] Changes made in Explorer (Model) lose part of document
    • [P-02] Performance problems while working with large XML documents
    • [P-04] Changes made in Explorer (Model) reformat document indentation
    • [E-01] Improve interconnection between source document and its Explorer presentation
    • [I-05] How should be modeled indentation?
  • [R-10] - Model Performance

    The Model must be prepared for large documents. There should be a special memory management to be able to parse, modify and merge a large XML documents.

    • [P-02] Performance problems while working with large XML documents
  • [R-11] - Semantic model mapping support

    XML Model is too generic. Concrete XML modules (e.g. Web Advanced with deployment descriptor support) prefer semantic API. There should be support for generating semantic API regarding to specified grammar. The generated API will transparently work over the Model to hide XML syntax.

    • [E-05] Users prefer semantics/logical Explorer views
    • [I-11] How could be solved semantic models?
  • [R-12] - Model navigation and querying

    The Model should be simply navigable. A powerful and suitable is [XPath] language.

3. Open issues

  • [I-01] - What is a relation to the XML Information Set?

    What should be relation to the [XML Information Set] technology? Is it just an inspiration for a new Model API? Or could be built the Model on it?

  • [I-02] - What is a relation to the XInclude?

    What should be relation to the [XInclude] technology? Does it relate to XML Information Set anyhow? Could not it be realized by some plug-in to the Model?

  • [I-03] - Should the Model always hold well-formed document?

    Not always is an XML or a DTD document well-formed. Should the Model be able to describe also non-well-formed document? Is not it dangerous?

  • [I-04] - What is a relation to an XML text editing?

    Source editor functionality: code completion, activated nodes, syntax highlighting, etc. relate to the Model (or at least syntax analysis). Is it possible to use a same Model instance for Tree and Text editor purposes? Could we share parser for syntax highlighting and also building the Model instance from document? What when a document is not well-formed (it is common while textual editing)? See [I-03] above.

  • [I-05] - How should be modeled indentation?

    Should be indentation solved by ignorable white spaces? Or could we have Model Settings to specify an Model indentation for a newly added item to a Model instance? This is concrete document meta-information, where this should be stored?

  • [I-06] - What is a relation to the DOM?

    Should we create to another API? Is it possible to reuse the [DOM]? Is it possible to fulfill our requirements by custom implementation of DOM API? Or is it better to provide DOM wrapper around custom Model API?

  • [I-07] - Should the Model provide Undo/Redo functionality?

    Is it necessary to provide Undo/Redo functionality at the Model side? Is not it too specific requirement? This could be solved by Source Editor Undo/Redo manager.

    • [E-02] Provide Undo/Redo operations on node tree representation
  • [I-08] - How deep should be a support for parameter entities?

    Parameter entity references (e.g. %ent-name;) can be practically anywhere, e.g.

        %pe;
        <!ELEMENT %pe1;>
        <!ELEMENT elem2 %pe2;>
        <!ELEMENT elem3 (%pe3a;|%pe3b;)>
    How should be handled such reference? Do we want/need to support parameter entity references inside declaration (i.e. pe1, pe2, pe3a, pe3b)? How could it be solved/described by the Model? Can we replace whole declaration when changed in an Model instance, i.e. resolve all used parameter entity references?
  • [I-09] - How to transparently work with entity references?

    Following simple document:

        <!DOCTYPE root [
            <!ENTITY attr    "attribute-value">
            <!ENTITY content "element-content">
        ]>
        <root attr="pre-&attr;-post">PRE-&content;-POST</root>
    describes following data:
    • An element item named "root".
    • An attribute item named "attr" with value "pre-attribute-value-".
    • An element content item with value "PRE-element-content-POST".

    How to work with the attribute value or with the element content? Should be value or content replaced by resolved value? Or should be thrown some Exception to notify used reference? Then, how could user resolve such situation?

  • [I-10] - How should be handled default values?

    Associated grammar can define default attribute value and also default element content if it is not specified in document instance. How to work with such attribute value or with the element content? Should be changed value or content inserted to appropriate place in a document instance? Or should be thrown some Exception to notify "read-only" value or content from the grammar? Then, how could user resolve such situation.

  • [I-11] - How could be solved semantic models?

    There are several tools that generate beans for appropriate DTD or XML Schema, e.g. schema2beans, or JAXB, etc. Could we reuse some parts of these tools? I would prefer JAXB that will be standard (JSR 31). Could we generate classes with same signature, but built over the XML Model?

4. References

XML
Extensible Markup Language (XML) 1.0 (Second Edition). World Wide Web Consortium (W3C). Available at http://www.w3.org/TR/REC-xml.
XML Names
Namespaces in XML. World Wide Web Consortium (W3C). Available at http://www.w3.org/TR/REC-xml-names/.
XML Information Set
XML Information Set. World Wide Web Consortium (W3C). Available at http://www.w3.org/TR/xml-infoset/.
XInclude
XML Inclusions (XInclude) Version 1.0. World Wide Web Consortium (W3C). Available at http://www.w3.org/TR/xinclude/.
XML Base
XML Base. World Wide Web Consortium (W3C). Available at http://www.w3.org/TR/xmlbase/.
DOM
Document Object Model. World Wide Web Consortium (W3C). Available at http://www.w3.org/DOM/.
XPath
XML Path Language. World Wide Web Consortium (W3C). Available at http://www.w3.org/TR/xpath.
Schema Language Comparison
Schema Language Comparison. The Schema Language Comparison Town Hall. Available at http://nwalsh.com/xml2001/schematownhall/slides/.
JDOM
JDOM. Available at http://www.jdom.org/.
dom4j
dom4j. Available at http://www.dom4j.org/.
XOM
XML Object Model. Available at http://www.cafeconleche.org/XOM/.
Electric XML
Electric XML. The Mind Electric. Available at http://www.themindelectric.com/exml/.
Sparta. Available at http://sparta-xml.sourceforge.net/.

Feel free to send comments to dev@xml.netbeans.org or attach them to issue #26478 .
 
 
loading
Please Confirm