[oXygen-user] [oXygen XML Editor Blog] - A Short Story of Reuse
Oxygen XML Editor Support (Radu Coravu)
Mon Sep 14 07:55:07 CDT 2015
Hi Robert,
We will not add any setting to make XML Schema 1.0 validation work in
other ways than described in the specification.
But we are working to have NVDL validation work with XML Schema 1.1. I
will get back to you when we have something which works.
Regards,
Radu
Radu Coravu
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
On 9/12/2015 7:14 PM, wrote:
> 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.
>
> <attributename="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>
> <restrictionbase="NMTOKEN">
> <enumerationvalue="skip"/>
> <enumerationvalue="lax"/>
> <enumerationvalue="strict"/>
> <enumerationvalue="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:
>
> *From:*
> [mailto:] *On Behalf Of *oXygen XML
> Editor Blog
> *Sent:* Monday, September 7, 2015 9:36 PM
> *To:*
> *Subject:* [oXygen-user] [oXygen XML Editor Blog] - A Short Story of Reuse
>
>
> [oXygen XML Editor Blog] - A Short Story of Reuse
> <http://blog.oxygenxml.com/>
>
>
>
> ------------------------------------------------------------------------
>
> *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>
>
>
> 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 oXygen XML Editor Blog
> <http://blog.oxygenxml.com/>
> To stop receiving these emails, you may unsubscribe now
> <https://feedburner.google.com/fb/a/mailunsubscribe?k=y_tRXtumvTurKTedh51JnlYsGXw>.
>
>
>
> Email delivery powered by Google
>
> Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United
> States
>
>
>
> _______________________________________________
> oXygen-user mailing list
>
> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
>
More information about the oXygen-user
mailing list