]> matita.cs.unibo.it Git - helm.git/blobdiff - helm/DEVEL/pxp/pxp/doc/EXTENSIONS
Initial revision
[helm.git] / helm / DEVEL / pxp / pxp / doc / EXTENSIONS
diff --git a/helm/DEVEL/pxp/pxp/doc/EXTENSIONS b/helm/DEVEL/pxp/pxp/doc/EXTENSIONS
new file mode 100644 (file)
index 0000000..a956839
--- /dev/null
@@ -0,0 +1,50 @@
+******************************************************************************
+Extensions of the XML specification
+******************************************************************************
+
+
+==============================================================================
+This document
+==============================================================================
+
+This parser has some options extending the XML specification. Here, the options 
+are explained. 
+
+==============================================================================
+Optional declarations instead of mandatory declarations
+==============================================================================
+
+The XML spec demands that elements, notations, and attributes must be declared. 
+However, there are sometimes situations where a different rule would be better: 
+If there is a declaration, the actual instance of the element type, notation 
+reference or attribute must match the pattern of the declaration; but if the 
+declaration is missing, a reasonable default declaration should be assumed.
+
+I have an example that seems to be typical: The inclusion of HTML into a meta 
+language. Imagine you have defined some type of "generator" or other tool 
+working with HTML fragments, and your document contains two types of elements: 
+The generating elements (with a name like "gen:xxx"), and the object elements 
+which are HTML. As HTML is still evolving, you do not want to declare the HTML 
+elements; the HTML fragments should be treated as well-formed XML fragments. In 
+contrast to this, the elements of the generator should be declared and 
+validated because you can more easily detect errors.
+
+The following two processing instructions can be included into the DTD:
+
+-  
+   <?pxp:dtd optional-element-and-notation-declarations?>
+   
+   References to unknown element types and notations no longer cause an error. 
+   The element may contain everything, but it must be still well-formed. It may 
+   have arbitrary attributes, and every attribute is treated as an #IMPLIED 
+   CDATA attribute.
+   
+-  
+   <?pxp:dtd optional-attribute-declarations elements="x y ..."?>
+   
+   References to unknown attributes inside one of the enumerated elements no 
+   longer cause an error. Such an attribute is treated as an #IMPLIED CDATA 
+   attribute. 
+   If there are several "optional-attribute-declarations" PIs, they are all 
+   interpreted (implicitly merged).
+