Re: [ebxml-bp] Specification xml fragment recheck in specification andits results: issue raised, please comment

Dale and team,
In line with our discussions with OASIS last week and to proceed, I've 
expanded our read-me from Committee Draft [original at 1].  I'd propose 
we inlcude this with the set of packages. For the errata, I would 
tentatively propose that we provide both examples recognizing the 
tooling preferences that may exist. If you (Dale) can clarify the 
examples, I can compile the errata for our consideration.  I'll have the 
other documents posted by in the morning.

Thanks.

[1] 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200604/msg00056.html 
(see: Readme explanation)

>moberg: In preparation for deciding about moving the CS to Oasis Specification,
>I was asked to check the examples in the specification once again....
>
>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? 
>
>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.
>  
>