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

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

Mark and NDRSC Team,

 

Correct me if I'm wrong, it was my understanding that the UBL Naming Design Rules Sub-Committee is trying to establish rules that eventually will be adopted by the larger ebXML community. I quote the NDRSC purpose from the Web site -- "The purpose of the NDR SC is to recommend to the TC rules and guidelines for normative-form schema design, instance design, and markup naming, and write and maintain documentation of these rules and guidelines." It has been my assumption (perhaps wrong) that the once the rules are adopted by the TC, they will be promoted within the larger ebXML community.

 

In my opinion, the scope of tag naming must go beyond the naming of tags for traditional business transactions. Within the illustration that I provided, the tagging of engineering data is only the tip of a much larger iceberg for back-office application to application integration.The tag naming rules that I am proposing are the rules one would use when assigning tag names to data within all structured databases used within an enterprise. The fact that engineering data needs to be shared in real B2B types of scenarios is simply an example of standardizing tag names for exchanging data between two or more systems within a B2B context.

 

I simply believe that this is such an important topic that if included within the scope of the NDRSC, it would enhance the potential adoption of the naming rules by the larger ebXML community.

 

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: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
Sent: Tuesday, February 26, 2002 4:34 AM
To: '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,

After looking at your paper, I am not convinced that adding the word document in the tag is necessary.  I understand what you are saying when you talk about ECP's, etc, but fail to see how the use of the word document makes it any clearer. Under your scenario, we would have a UBL schema with a differentiated top level tag name for every possible engineering data element.  A much simpler approach would be to create a single schema for <SharedEngineeringData> with a host of optional data elements.  No need to use document in the top level tag, as (1) it is not a document, (2) the concept of documents is what we are trying to get away from, and (3) I can certainly garner the intent of the transaction from the proposed tag. 

On a separate note, please remember that the UBL community and ebXML community are not necessarily one in the same.  There is a clear overlap in interest, especially vis a vis the use of the core components specification, but we in UBL are not defining document structures for ebXML.  No one has taken on that task yet.

Mark

> -----Original Message-----
> From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
> Sent: Monday, February 25, 2002 2:48 PM
> To: 'Matthew Gertner'; 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
>
>
> 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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>