RE: Long Tags Codes etc. again

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Folks:
 
Just a comment about the differences between EDI formats and XML: XML tools
tend to be very good at using nesting to qualify semantics. Technologies
like XPath and XSL are built around this premise, it being a very typically
way of modelling in XML. What XML is not so good at is handling the use of
qualifying codes to carry semantics, which is more a cornerstone of EDI
syntax. (XML schema gives up some capabilities in this arena, by recognizing
enumerated datatypes clearly, but I don't think we can describe this feature
as "mature".)
 
I am not voicing an opinion about the current discussion here, but I do want
to point out that while nesting may not be a very familiar technique to many
users, it is a very standard XML modelling technique. Everything is seen as
a tree structure, or a set of nodes related primarily by their hierarchical
relationships, as in most object-oriented technology. This allows
inheritance - of semantics, of behaviours, etc. - down a tree.
 
If we are looking forward to a world full of distributed systems, based on
object technology, then perhaps considering this in our approach to
semantics is not a bad idea.
 
Cheers,
 
Arofan Gregory

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


Philip,
 
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.  
 
Mark 
-----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 
 
<SellerParty>
<Name>
 
instead of <SellerPartyName>
 
as the Name will be nested 
 
<SellerParty>
<Name>
</Name>
</SellerParty>
 
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 ----- 
From: CRAWFORD,  <mailto:MCRAWFORD@lmi.org> Mark 
To: 'ebXML Core' (E-mail) <mailto:ebxml-core@lists.ebxml.org>  
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
 
<SellerParty>
<Name>
 
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 
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 
mcrawford@lmi.org 
http://www.lmi.org <http://www.lmi.org/>  
"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


Hi,
    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:
 
    <SellerPartyName>
 
    You get;
 
    <SellerParty>
        <Name>
 
    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 
martin.me.roberts@bt.com 

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


Hi,
 
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


 Folks
   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