[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ubl-comment] ARTS comments on NDR dist #2
FYI-- The following comments from the ARTS (retail) organization were
sent on NDR distribution #2. I will try to respond to as many points as
possible in a followup posting. Many thanks for the comments!
Eve
-------- Original Message --------
You asked for comments, my first set of comments are about the document
presentation. As you will be aware this is a particular bug-bear of
mine. If any standards committee is producing multiple documents, then
the documents should look like they form part of a coheren, well-thought
out whole. Major presentation inconsistencies between supposedly
related documents impedes acceptance.
Hope this all gets to you in time.
Regards,
Stuart
*_Document Presentation:_*
First up the package contains six PDF files and although the content
seems to be good:
*a.* One document is still an SAP internal document not using the OASIS
template
*b.* There are two different versions of the OASIS logo in use.
*c.* A couple of documents are obviously written by someone for whom
English is not a first language, the consequent grammar mistakes make
the documents very difficult to read.
**
*d. *There is no consistency in how XML and XSD Schema fragments are
presented in the various documents. As this is an XML initiative, it is
not unreasonable to expect that XML & XSD Sschema fragments would be
presented in a 'house style'.
*__*
*_Global vs. Local:_*
*a.* The abstract doesn't inform the reader that the document is a
proposal to change a previous guideline.
*b.* Lines 46 & 47 of the introduction states the original guideline but
does not (and should) continue with a short statement of the problems
that this guideline has created. Introduction should conclude with a
short statement that the remainder of the document proposes a solution
to these problems.
*c. *Although the example XML instance documents on lines 268 - 300
illustrate the problem being solved: (extension writers end up having to
qualify every name in every instance document). The problem is never
stated, and nor are the ramifications and likely consequences of those
problems discussed.
*d.* Line 402 "4.2 Globally Qualified Solution" should be "4.2 An
Alternative Solution", make it clear that this is a proposal for change.
*e.* The author has decided he (she?) is proposing one solution to the
stated problem. Are there other ways of extending the UBL schemas with
out having to us name-space qualifiers everywhere? If so then more
possibilities should be discussed. It is after all a position paper,
which is attempting to convince the reader to agree with the author.
*__*
*_Facets:_*
*a.* This document is obviously a very early working draft, it needs to
include a description of what facets are, with an example, and why they
need to be used, perhaps just http: link to appropriate W3C documentation.
*_Code Lists_*
*a.* Line 67, a reference to the guideline outlining the use of 'Codes'
in UBL is appropriate. Other XML vertical initiatives have decided that
codes are to be used in a very limited fashion (if at all). A reader new
to UBL may need such a reference.
*_Elements vs. Attributes_*
*a.* * *There appears to be no rules about removing words deemed to be
spurious because of the hierarchical nature of XML, Example:
<Order>
<OrderHeader>
<From/>
<To/>
</OrderHeader>
<OrderBody>
<OrderLineItem/>
<OrderLineItem/>
</OrderBody>
</Order>
Could become, because the XML nesting hierarchy provides sufficient context.
<Order>
<Header>
<From/>
<To/>
</Header>
<Body>
<LineItem/>
<LineItem/>
</Body>
</Order>
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC