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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] UBL v2 Rev - #2


[cheekai@softml.net:]

| Below refers to UBL v2 working draft package at Jon's URL
| 
|    http://ibiblio.org/bosak/ubl/wd-UBL-2.0.zip

It should be understood that this URL was set up to allow internal
testing of the preliminary build by members of the UBL TC; it was
not (and is not) intended for public access.  The draft has not
been approved by the UBL TC and has no official status whatsoever.

| - It is mentioned in "index.html" Appendix D that UBL's NDR 2.0 
|   "will be released as part of UBL 2.0 publication".  If there are
|   differences detected in this working draft schema set, it would
|   be very difficult for us on ubl-dev to check whether it is a 
|   deliberate difference due to changes in NDR 2.0, or due to 
|   schema generation problems, or editing, or other possible 
|   sources.

Q/A of the NDRs against the initial schemas is on the agenda of
the UBL TC meeting scheduled for 23-27 January.  The deliverables
of that meeting will include a public draft of the NDR document
and a list of issues identified during the meeting.  That's the
point at which it would be useful to help in identifying problems
not caught by the TC.

There appears to be some confusion surrounding the concept of a
public review.  One of the primary purposes of the initial public
review is to formally request the public's help in finding errors
in the public review draft.  We all expect that there will be
quite a few of them in a project of this size.  The idea of holding
the initial public review is to freeze the specification for 60
days so that people aren't trying to evaluate a moving target and
so that the comments received can all be logged and then processed
against a single draft.  That draft has not been released yet.
When it is, we will let you know.

| - File "wd-UBL-2.0.pdf", the PDF version of "index.html", appears
|   to have many of its diagrams cut off on their right.  In addition,
|   other than the unwanted "<?xml version=....>" stuff on the 
|   first page first line and the "Copyright 00A9; 2001-2005 OASIS..."
|   on the last page first line, some of the relative hyperlinks
|   such as those pointing to xsd and xls  don't work (when clicked,
|   browser points to C:\d\ubl\2\mod\lib\UBL-CommonLibrary-2.xls",
|   for instance).

The PDF file was automatically generated and included in the
package to satisfy a provision of the current OASIS process that
requires OASIS specifications to be provided in PDF; see

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

The UBL specification actually consists of over 100 files in
several different formats that are made navigable by a single
XHTML file (valid against the XHTML 1.0 Strict DTD, by the way).
In other words, it is a classic hypertext.  This is the
specification as created by the TC.  The PDF file is provided
purely to satisfy the letter of the process provision and has no
further function; this is why I didn't even bother to remove the
junk at the top.  The PDF file is at best perfectly useless, and
as Bryan Rasmussen has pointed out, opening it in an MS Windows
environment may even be dangerous at the moment.  Please don't
bother filing reports against it.

| - For CoreComponentParameters-2.xsd, there appears to be a dangling
|     <xsd:element name="Instance" type="InstanceType" />
|   The InstanceType is also defined and used by this dangling element
|   defintion, so that InstanceType is also dangling.

If it doesn't cause an actual validation failure, we're not
interested in this kind of problem till the public review begins.
Once that starts (we will let you know when), please file this
issue using the comment form linked to from the draft.  Note that
the OASIS process requires comments to be submitted through this
form in order to be formally considered.

| - In the model spreadsheet, there are many columns of "Small Business
|   Subset ..." (columns AF to AW).  And some of these cells have "Y"
|   as data.  Since XSDs are the only normative product of UBL v2, should
|   it not be the case that these SBS column values are transported and
|   stored into XSD's documentation tags?  Otherwise those values might
|   be lost in the spreadsheets which are "non-normative".

The SBS is a separate specification that has no normative status
within the UBL specification itself, so it's appropriate that the
SBS flags stay in the spreadsheets.  Since SBS 2.0 development has
to build on UBL 2.0, we would also be creating a scheduling
problem if we froze the SBS flags into the normative part of the
UBL spec.

To sum up: If you find any validation errors, let me know.
Otherwise, you're wasting your time at this point.  Save your
comments for the public review.

Jon




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