oXygen Editor, Radu, et al. I agree. However, you have omitted the largest potential use, which is. making XHTML5 pages based upon elements in XML pages that are validated by XSD1.1. The XHTML5 pages produced with schema based elements together with other XML based files can then be included in EPUBs. This means that you can create a WISIWIG word processor that is better than Adobe FrameMaker. In fact, this word-processor can be extended to have smart tables and serve as an Office type application that could compete with Microsoft Office. It could also be augmented with DITA or DocBook elements and should facilitate the preparation of structured documents including forms. These structured documents can also be stored together as an EPUB, which is effectively an open, portable standard and could compete with PDF. This technology would facilitate medical and other high-technology informatics. The main problem is to surround elements from one schema that were derived from complexTypes and/or their components with elements from a second independent schema. Interleaving of elements from two schemas is not possible when an element from the first schema surrounds an element of a second schema that was derived from a complexType. Previously, I have done some empirical testing with Radu on the meaning of skip as a value for the processContents attribute of a defaultOpenContent element. Unfortunately skip does not mean ignore. The following cannot be completely validated <p>xml:ComplexType with multiple elements</p> Where <p>is an XHTML formatting element, whose purpose is to tell CSS to format the contents of an element whose type is xml:ComplexType. I learned by experiment, that when the element from the second schema is complex, I cannot validate the XML page, which contains surrounding XHTM5 formatting elements: <p>. <h1>, <h2>, etc. That defaultOpenContent elements in its present form does not work. Since this is the result of the processContents attribute value, skip, not meaning ignore, an ignore attribute value should be added to the values of the processContents attribute. This ignore value containing attribute would instruct the parser of the second schema to treat the elements from the first schema as either white space or possibly no space. It would not tell the parser that an element was present. There are two solutions: 1) change the XML schema as described in structures.xsd or 2) Radu Coravu’s suggestion to update NVDL to work with XSD1.1. Actually, it probably would be useful to do both.
From attached structures.xsd, which was in good part abstracted from
XMLSchema.xsd (http://www.w3.org/TR/xmlschema11-1/XMLSchema.xsd. <attribute name="processContents" default="strict" use="optional"> <simpleType> <annotation> <documentation>Solution 1: I added ignore to the enumeration. This validates and is the simplest fix; however, it would provide a new choice for every processContents, which validates. processContents is used approximately 30 to 40 in the XMLSchema.xsd. The ignore value for the enumeration can be commented out. (http://www.w3.org/TR/xmlschema11-1/XMLSchema.xsd) </documentation> </annotation> <restriction base="NMTOKEN"> <enumeration value="skip"/> <enumeration value="lax"/> <enumeration value="strict"/> <enumeration value="ignore"/> </restriction> </simpleType> </attribute> Since this solution is backwards compatible, it should not break any existing code and should be relatively inexpensive to implement. <defaultOpenContent mode="interleave"> <any namespace="##other" processContents="ignore"/> </defaultOpenContent> Another approach was to create a new element, ignoreContent, which is also described in structures.xsd. Two XML pages, ignoreContent.xml and openContent.xml were generated from structures.xsd and are attached. I would greatly appreciate your thoughts on the addition of ignore, as well as any thoughts of making XHTML5 documents based on xsd1.1 as the primary format for commerce and science. Could oXygen modify the preprocessor for the Saxon and Xerces parsers or induce their creators to make the ignore change. The use of the ignore change could be voluntary and depend on a choice in the schema menu. I believe that the use of standard HTML markup to form XHTML files would increase the market for oXygen or a derivative product. Yours respectfully, Bob Leif Robert C. Leif, Ph.D. Research Director Newport Instruments 3345 Hopi Place San Diego, CA 92117-3516 Tel. 619.582.0437 Email: rleif@rleif.com From: oxygen-user-bounces@oxygenxml.com [mailto:oxygen-user-bounces@oxygenxml.com] On Behalf Of oXygen XML Editor Blog Sent: Monday, September 7, 2015 9:36 PM To: oxygen-user@oxygenxml.com Subject: [oXygen-user] [oXygen XML Editor Blog] - A Short Story of Reuse <http://blog.oxygenxml.com/> [oXygen XML Editor Blog] - A Short Story of Reuse _____ <http://feedproxy.google.com/~r/AboutOxygenXmlEditor/~3/-bqdMBmNY0Q/a-short-story-of-reuse.html?utm_source=feedburner&utm_medium=email> A Short Story of Reuse Posted: 07 Sep 2015 02:38 AM PDT Give the smartest human in the world a piece of wood and ask him/her to make paper. Give him/her no prior tools and it will take years to come up with a decent process which would result in some brown almost usable thick piece of paper. This blog post is about reuse, not necessarily reuse of tools and materials, but reuse of knowledge. Humanity has evolved not because each generation is smarter than the last one but because we learned to reuse and pass knowledge to larger and larger audiences and from one generation to another. Almost all tools that we use today are made up of quite a complex set of components which interact with each other. There is no one person in a car assembly factory who still knows all the pieces and how they come together. Although using the tool is easier than interacting with all components which make it up, you still need knowledge to operate it and in this day and age having enough people to teach how a certain tool can be used is no longer an option. You need to pass knowledge in other forms, on paper or in some kind of digital form. So I would define technical communication as a means of passing knowledge about using tools to a larger audience. Reuse in technical communication can be structured on many levels: * Reuse written content by publishing it to more than one format (PDF, HTML, EPUB, MS Word). It turns out that XML is perfect for publishing content in more than one format. XML is not designed to be consumed directly by end users and its benefit lies directly in this. Your XML content should contain all the data necessary for obtaining all the output formats. So if you are using XML in your technical content, no matter what standard or custom vocabulary, you can safely check the first and most important level of reuse. * Create larger publications from existing ones. Either using an XML standard like XInclude or using standards with their own diverse and powerful methods of reuse like DITA, or by performing custom techniques you can merge XML content in larger publications. * Reuse content written for a certain tool to document the functionality and behavior of a very similar tool. In most mature XML standards like DITA and Docbook there is this implemented concept of profiling which allows you to dynamically filter at publishing time content marked with certain attributes from your original XML project. In this way from the same XML content you can publish documentation for multiple similar tools. * Reuse smaller pieces of common content in more than one publication. Again, using XML standards like XInclude or DITA specific standards like content references you can create and maintain small libraries of reusable XML content, then reuse these components across various publications. * Reuse images and other binary resources in multiple publications. Because XML content does not embed binary resources, these resources are stored separately and thus they can be reused in multiple places. So these are what I consider to be the main selling points for using XML in technical documentation. As usual any feedback is welcomed. <http://feeds.feedburner.com/~r/AboutOxygenXmlEditor/~4/-bqdMBmNY0Q?utm_source=feedburner&utm_medium=email> You are subscribed to email updates from <http://blog.oxygenxml.com/> oXygen XML Editor Blog To stop receiving these emails, you may <https://feedburner.google.com/fb/a/mailunsubscribe?k=y_tRXtumvTurKTedh51JnlYsGXw> unsubscribe now. Email delivery powered by Google Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States