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
-----Original Message-----
From: CRAWFORD, Mark
[mailto:]
Sent: Tuesday, February 26, 2002 4:34
AM
To: ''
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:]
> Sent: Monday, February 25, 2002 2:48 PM
> To: 'Matthew Gertner'; Schuldt, Ron L;
> ''
>
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
>
>
>
> -----Original Message-----
> From: Matthew Gertner [mailto:]
> Sent: Monday, February 25, 2002 10:57 AM
> To: 'Schuldt, Ron L';
''
> 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:]
> > Sent: Thursday, February 21, 2002 12:45 AM
> > To: ''
> > 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
> >
>
>
>
----------------------------------------------------------------
> 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>
>
