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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: RE: [ubl-ndrsc] Draft Partial Document Use Case - Justification f orDocument at the Top Level Tag Name


Ron,

I understand that the point argued in this paper is that the reader of a
document will want to know what the physical representation of the top-level
tag of a document is: is it also a document (albeit a paper-based one), a
person, a process, etc. If this is really a problem then I agree with you,
we should add the Document suffix to top-level tag names as appropriate.

That said, I can't think of any examples where this is needed. The tag name
of components tend to describe what they are anyway (i.e. Address, Party,
Price, etc.). Since there are no suffixes here, I can't see how the Document
suffix adds value. The only real justification I can think of is the case of
ambiguous tag names. Everyone knows basically what an Invoice or Goods
Receipt Note is, so tacking on Document doesn't add much. You might point
out that Order is ambiguous, but I would argue that renaming it
PurchaseOrder is a lot more sensible that calling it OrderDocument.

There are also some arguments against this idea:
1) It makes UBL more verbose. This reduces conciseness, one of our stated
design goals, and should be avoided if possible.
2) Some document names already end with the appropriate description (Advance
Shipment Notice, Goods Receipt Note, Dispatch Notice, etc.). It would seem
rather strange to have a tag called AdvanceShipmentNoticeDocument or so.
Making exceptions would, however, destroy the consistency that was the major
goal in the first place.
3) There are edge cases where it would be hard to decide whether to add the
Document suffix or not. Take your example of ChangeRequest. Is this a
Document in your sense or not? It might be an electronic version of a paper
document (in which case it probably is), or a new structure invented for the
purposes of creating an electronic solution (in which case it probably
isn't). Document designers have a lot of tough design decisions, so we
should avoid creating new ones if possible.

In summary, your document answers one question (why would you add the
Document suffix) but begs many others.

I apologize if this seems negative. There's a good chance I am missing
something important. In general I'm against adding more baggage to tag
names, so I'll tend to play the role of devil's advocate on this type of
issue.

Regards,
Matt

> -----Original Message-----
> From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> Sent: Thursday, February 21, 2002 12:45 AM
> To: 'ubl-ndrsc@lists.oasis-open.org'
> Subject: [ubl-ndrsc] Draft Partial Document Use Case - Justification for
> Document at t he Top Level Tag Name
> 
> Team,
> 
> Per today's discussion, I took the action to author a use case to justify
> using the word "document" in the top level tag name for those UBL
> predefined
> documents.
> 
> Attached is the first draft of a proposed use case wherein a partial
> document - perhaps even at the extreme of extracting individual data from
> a
> database is the foundation for my opinion/recommendation.
> 
> As noted in the action item, I need to have Sue forward this to the LC
> list.
> 
> 
>  <<draft-schuldt-partial-doc-use-case-01.doc>>
> Ronald L. Schuldt
> Senior Staff Systems Architect
> Lockheed Martin Enterprise Information Systems
> 11757 W. Ken Caryl Ave. #F521 MP DC5694
> Littleton, CO 80127
> 303-977-1414
> ron.l.schuldt@lmco.com



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


Powered by eList eXpress LLC