OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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

Subject: RE: Long Tags Codes etc. again

There seems to be a lot of good requirements in this thread.  Maybe a view to an existing implementation would be of assistance.
The structure associated with Tags should be in response to requirements.  There have already been many requirements expressed with respect to message construction, most having to do with proper encapsulation, reuse, and matching to enterprise specific representations.
When Edifecs was presented with the task of constructing RosettaNet guidelines in 1999, we were faced with the same basic set of requirements.  We applied object philosophy to these requirements and came up with the structure in the attached document (based on our existing standards construction tools and experience).
Note that any one XML block (block defined as being within a tag hierarchy) represents a BusinessDataEntity (BDE).  These BDEs are reusable information structures, and represent business objects.  These BusinessDataEntities are specialized in one of the following subclasses:
 - FundamentalBusinessDataEntity(FBDE): has a data representation (min/max/pattern) and no composite tags.
 - QuantativeFundamentalBusinessDataEntity (QFBDE) contains a measurement and references a system of units
 - CoreComponent is a reusable structure that represents a property and does not represent an identifiable business object (uniquely identifiable instance)
 - CommonBusinessObject is a reusable structure that represents an identifiable business object (e.g. product, factory, etc)
 - UseAggregation is a structure related to a specific use of a set of objects and properties
 - DocumentSegment is a structure which encapsulate a section of a document for reuse, validation, or processing requirements
 - Document is a structure which encapsulates a document which must be complete to be valid in a business context.
Note that BDE, FBDE, and QFBDE are RosettaNet specific names.  In the attached diagram these are referenced as Entity, FundamentalEntity, and QuantitativeFundamentalEntity.
Note that FBDE, QFBDE, CoreComponent, and CommonBusinessObject exist across use case boundaries.  Note that UseAggregations will always be bounded by some high level use case.
The other concept that should get first class status is that of Role.  When a block has a specific use in a context, that does not create a new block, it creates a role for that block.  For instance a seller is a Role for a Party.  The Party block should clearly identify that it is a representation of a Party entity, so that any interface able to deal with parties can process it without special coding.  Calling it <SellerParty> clearly defeats that requirement.
For compliance with UML, the role starts with a lowercase, while an entity starts with uppercase.
This type of structure, and the ability to specialize it as described in the accompanying diagram is critical to consistent construction and use.
The point is that roles allow clearly labeled and constructed reusable blocks, and that subclassing the compositional blocks allows clear guidelines that can ease construction of efficient interfaces.
Sorry about not offering this sooner, I was focusing on the process side :-)

 -----Original Message-----
From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
Sent: Tuesday, April 17, 2001 9:52 AM
To: 'ebXML Core' (E-mail)
Subject: RE: Long Tags Codes etc. again

I must respectfully disagree.  If you are going to rely on nesting, then you needlessly magnify the complexity.  Even with nesting, there is still the problem with properly identifying context.  <SellerPartyName> clearly identifies what I am conveying - without having to refer to where the tag is nested in a stream of data.  It's not an issue of dumbing down to support the uneducated, it's more an issue of what makes good sense from the user perspective. 
-----Original Message-----
From: Philip Goatly [mailto:philip.goatly@bolero.net]
Sent: Tuesday, April 17, 2001 8:49 AM
To: CRAWFORD, Mark; 'ebXML Core' (E-mail)
Subject: Re: Long Tags Codes etc. again

Hello Mark,
   Please point us to the code naming conventions document.
 Also I don't think Martin has a problem - nor should the user with the
instead of <SellerPartyName>
as the Name will be nested
The casual reader will have to understand the concept of nesting of course, but we cannot assume with anything new that people will not have to learn anything, or is that our aim ? ;-)
Cheers, Phil
----- Original Message -----
Sent: Tuesday, April 17, 2001 1:17 PM
Subject: RE: Long Tags Codes etc. again

Martin thinks w should use the context of the previous tags to add meaning.  He argues we should use
instead of <SellerPartyName>
I would be curious to know how Martin thinks the lay reader will be able to discern the relationship between <SellerParty> and <Name> unless he refers to the document schema.   
I think we have gotten it right with the core components naming conventions, and wonder why we don't just adopt both the naming conventions - and the CC names developed in compliance with those naming conventions, as our tag methodology.   

Mark Crawford
Research Fellow - XML Lead
E-business Strategies
Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177   Fax (703) 917-7518
Wireless (703) 655-4810
"Opportunity is what you make of it"

-----Original Message-----
From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com]
Sent: Tuesday, April 17, 2001 7:41 AM
To: mblantz@netfish.com; philip.goatly@bolero.net; ebxml-core@lists.ebxml.org
Subject: RE: Long Tags Codes etc. again

    One way to get round this is to use the context of the previous tags to add meaning and hense you don't end up with:
    You get;
    The amount of characters is the nearly the same but the tags are short.
    Getting XML messages on one screen is almost impossible as you end up saying xml messages must be only 24-60 lines long as traditionall XML is shown with one element per line.

Martin M.E. Roberts
xml designer, BTexaCT
01473 643775

-----Original Message-----
From: Blantz, Mary Kay [mailto:mblantz@netfish.com]
Sent: 17 April 2001 12:39
To: 'Philip Goatly'; ebXML Core
Subject: RE: Long Tags Codes etc. again

Speaking just as me, and not wearing any hats at all...
If we do this right, then many small enterprises will be exchanging info electronically for
the first time.  Just as new users did with traditional EDI, I suspect the majority will start
with just displaying the data on their computers.  In this case, it would be good if all
the information was on one screen.
So, I vote for short but meaningful tags. 
Mary Kay
-----Original Message-----
From: Philip Goatly [mailto:philip.goatly@bolero.net]
Sent: Tuesday, April 17, 2001 4:47 AM
To: ebXML Core
Subject: Long Tags Codes etc. again

   It has been said

 1.  Human readability by domain experts as well as software specialist,
 is a requirement for XML documents.

  Yes true, but if we were to adopt a 'code' as a tag then it would still be
 human readable i.e it is ASCII but the meaning would be obscured to the
 casual/uneducated reader. It is not beyond the wit of comptuing to look up
 the 'code' and make it friendly to the casual reader. Also, given the
 human reader could have some language other than English as his/her mother
 tongue, then the look up could be keyed on Language Code + tag code. Is this
 even better than having a long English tag?

 Even with 'long' tag names, which allow readability in English, there
 still remains a problem, in that the tag does not convey the complete
meaning - otherwise we would not need any semantics at all.

 Again we must ask a similar question to the one which I posed before.

 How much of the semantics should be in the tag and how much in the
 actual semantic description of the element.

 There is a temptation to write an 'essay' in the tag.

 Anybody got thoughts on this one ?

 Cheers, Phil


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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC