OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Specification xml fragment recheck in specification and its results: issue raised, please comment

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 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"



to using


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



[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;




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]