Next in thread →
Next in month →
RE: [ubl-ndrsc] Draft Partial Document Use Case - Justification f orDocument at the Top Level Tag Name
Title: RE: [ubl-ndrsc] Draft Partial Document Use Case - Justification f or Document at the Top Level Tag Name
Ron,
Once again, there is no
direct relationship between UBL and ebXML, and UBL is not part of the ebXML
community. In fact, a project proposal submitted to the eBTWG for a
liaison with UBL was rejected by the short sighted eBTWG management
team.
We are tackling a space
that was conspicuously avoided by ebXML - XML syntax specific instantiations of
business information exchanges based on BIEs and CCs. Our products of
course could be adopted by the business standards body of UN/CEFACT whose focus
is exclusively business transactions, and that I believe is our long term
goal.
Mark
[CRAWFORD, Mark] -----Original
Message-----
From: Schuldt, Ron L
[mailto:]
Sent: Tuesday, February 26, 2002 10:09
AM
To: 'CRAWFORD, Mark';
''
Subject: 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>
>
Next in thread →
Next in month →