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