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: RE: [ebxml-bp] Specification xml fragment recheck in specificationand its results: issue raised, please comment


If the strictness of the rules means we cannot even change
such a character then I guess we'd have to keep all mention
of committee draft except on the title page as it is too -
or revote. Maybe this means we have to make all the changes,
check everything is exactly as it should be in the committee
spec, check again nothing other than the title page needs
changing for it to become a standard (** I guess that means no
mention of committee draft, committee spec or anything like it
except on the title page **) and revote when all is definitely
OK.

All the best

Steve



Quoting "David RR Webber (XML)" <david@drrw.info>:

> 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" <dmoberg@cyclonecommerce.com>
> Date: Wed, May 03, 2006 11:46 am
> To: <ebxml-bp@lists.oasis-open.org>
>
>  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&rsquo;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 &ldquo;xpointer scheme&rdquo;
> but instead, if they support the include/@xpointer attribute at all,
> appear to make use of the &ldquo;element scheme&rdquo;. 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 &ldquo;signals=package-2.0.3.xml&rdquo;
> 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





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