RE: [ebxml-bp] Specification xml fragment recheck in specification and its results: issue raised, please comment

Dale,

 

I'd definately put these items in the typos and corrections column -
these are all things to do with formatting and such and proof
reading.  

 

Thanks, DW

 

p.s. That rascal " double quote in Word is a gnarly one - because its
also not in the base ascii char set but is in UTF-8!

-------- Original Message --------
Subject:
[ebxml-bp] Specification xml fragment recheck in specification
and
its results: issue raised, please comment
From: "Dale Moberg"
<>
Date: Wed, May 03, 2006 11:46
am
To: <>

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; 

at

 

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