Since I find myself working on this today, here are some answers:
Eve L. Maler wrote:
> Looks great! It's a model of clarity, the examples are extremely
> helpful, and I find it a relief to see such clear <context> syntax. :-)
But the formatting is a royal pain, I can't use Word and Matt doesn't
want to use OO, so I've converted the whole thing to XML and that's what
I'm now editing. Next version you see will be XHTML.
> I have just a few comments:
>
> - General questions: Will the "shoulds" and "musts" here ultimately be
> turned into numbered Rn rules? Is this document destined to be folded
> into the NDR document?
I believe the question was answered in the negative this past Wednesday.
>
> - General comment: There are a number of little stylistic and
> copyediting needs and the graphics could be normalized a bit. E.g., the
> "Customization through other means" header (line 283) has some weird
> page breaking going on around it. I might be able to help with this
> sometime next week, if desired.
I believe I've made the formatting issues moot ;)
As to the graphics, my copy of OpenOffice does not show them because I've
deleted them. However, every time I convert OO into Word, the graphics
reappear, like in some horror movie. With the conversion to XML, this
should not be a problem.
>
> - One-per-context (line 114): I'm sure this is treated below, but the
> rule is more subtle than expressed here, right? It's not that
> particular slot (context driver) out of the eight can't be used again,
> but the value in that slot (the "context") must be more specific than
> the previous value supplied for that slot (if any) in the derivation chain.
You are absolutely right and this will change.
I have not looked at the rest yet, and may not get to it today. When I
do I'll send another note.
THanks, Eve!
>
> - "Explicit" type definitions (line 172): I would say "named" rather
> than "explicit", because both named and anonymous types are explicit
> (that is, they both have a complexType or simpleType element around them).
>
> - Requiring the use of a derived type (line 179): Doesn't the derived
> type have to be bound to an element in the user's namespace in order to
> require use of the new type instead of the base one? It doesn't quite
> say so here (or does the next bullet say it for a different reason?).
>
> - Deletion of required components (line 286): The general case should be
> stated as x..y to x-1..y. 0..y is just an example of a particular kind
> of reduction.
>
> - Abstract ur-types (line 299): I don't quite understand this graphic.
> Where does d,e,f get added on the ultimate type on the left? And
> shouldn't one example derivation in the picture be shown emanating from
> the abstract level rather than the derive 80/20 level?
>
> Eve
>
> Eduardo Gutentag wrote:
>
>> On behalf of Matthew, who seems to be unable to post to this list (and
>> come to
>> think of it, I don't even know if I can, we'll see). I just saw this, so
>> I have not read it at all. So, sight unseen, I'll venture that it
>> still needs
>> more and better examples :)
>>
>> Dan Vidt expressed willingness to work w/me on examples. Dan, you
>> still there?
>>
>> Quoting from Matt's message to me:
>>
>> "The document seems great to me. I only made a few editorial changes. I
>> think the important next step is for this to be reviewed by other
>> members of the UBL TC (particularly the LC and NDR subcommittees) and to
>> be looked at by potential users (not sure how to sollicit feedback on
>> this). My biggest concern is that much of the content of the document
>> may not be sufficiently clear for a UBL newbie; obviously as a co-author
>> it is hard for me to make a judgement on this."
>>
>>
>>
>
--
Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards | Phone: +1 510 550 4616 x31442
Sun Microsystems Inc. | 1800 Harrison St. Oakland, CA 94612
W3C AC Rep / OASIS TAB Chair