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


Title: 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>
>



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


Powered by eList eXpress LLC