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

["Schuldt, Ron L" <ron.l.schuldt@lmco.com>]

Matt/NDRSC Team,

The issue I am trying raise is when an engineering collaboration scenario
requires sharing of structured data from engineering systems that CANNOT be
pre-defined in a "document" per se (e.g., mass properties data, dimensions
data, max/min temperature tolerances, etc). The example I provided is an
attempt to illustrate one such scenario - very real within the aerospace
industry as well as perhaps others such as automotive - both highly
dependent on the sharing of engineering data - NOT the sharing of
traditional transactions (such as those in your reply) that seem to be the
only scope of interest to the ebXML community. I guess I am really trying to
open the eyes of the ebXML community to a requirement (at least within the
aerospace industry) to standardize XML tag structures for objects other than
traditional EDI objects.

For your consideration, the ebXML mission on the ebXML Web page states 
"To provide an open XML-based infrastructure enabling the global use of
electronic business information in an interoperable, secure and consistent
manner by all parties." If engineering data is considered out-of-scope for
ebXML, then I'll take my issue elsewhere and solve it elsewhere. 

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


-----Original Message-----
From: Matthew Gertner [mailto:matthew.gertner@schemantix.com]
Sent: Monday, February 25, 2002 10:57 AM
To: 'Schuldt, Ron L'; 'ubl-ndrsc@lists.oasis-open.org'
Subject: RE: [ubl-ndrsc] Draft Partial Document Use Case - Justification
f or Document 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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>