Specification xml fragment recheck in specification and its results: iss

In preparation for deciding about moving the CS to Oasis Specification, I was asked to check the examples in the specification once again.

The examples occasionally delete some required elements, whose absence is noted by a comment. I assume this editorial liberty is OK. Also, the ID values referenced in some fragments actually occur elsewhere, so occasionally a missing ID value for an IDREF data type is noted by a tool. I also assume this is OK and we can note this fact in response to item c (see below for requirement c). It is impossible to both have focus on the fragment and have all the referenced items included in the immediate text so I think this is inevitable when using illustrative bits of XML in the text.

Unfortunately, in the .doc format, for section 3.4.6.3 on using xinclude, some of the quotation marks have been converted to the matching quotation mark values, and if the fragment is checked in Oxygen 7.0, for example, a well-formedness complaint is issued. Also, in that example, the xinclude statement is commented out (probably a result, ironically, of checking the fragment for validity; validity check requires that the xinclude insertions be carried out before the schema check). This means the example doesn’t actually technically have an xinclude in it, but just a comment. Will people be confused?

Note that any change except on the title page requires that revote the CS status unfortunately.

If we do decide to revote for CS editorial changes like this, I would suggest one more adjustment to align the example with open source implementations of xinclude that I examined. Many of these implementations do not implement the “xpointer scheme” but instead, if they support the include/@xpointer attribute at all, appear to make use of the “element scheme”. Here is what the difference would look like

From now using

<xi:include href=""signals-package-2.0.3.xml"" parse="xml"

xpointer="xpointer(/ProcessSpecification/Package[1])"/>

to using

<xi:include href=""signals-package-2.0.3.xml"" parse="xml"

xpointer="element(/1/1)"/>

[This assumes that the file “signals=package-2.0.3.xml” is in the current working directory, usually, but implementers should eventually figure that out.

If the TC favors making these editorial updates, I suggest we also change to use the element scheme so that implementers have an example to try out that is closer to working with widely available open source tools.

Here is the point c in the OASIS requirement that we need to fulfill prior to OASIS specification vote.

· Certification by the TC that all schema and XML instances included in the specification, whether by inclusion or reference, including fragments of such, are well formed, and that all expressions are valid;

http://www.oasis-open.org/committees/process.php#3.4

ebxml-bp message