Re: Long Tags Codes etc. again

[Philip Goatly <philip.goatly@bolero.net>]

Hi Todd,
                If we are going to do that then why not

<X001 Name="SellerPartyName">
</X001>

If the attribute Name were #IMPLIED ( i.e.optional then it could be in any
language and for the guys who like to save
band width could just be :
<X001>
</X001>

But perhaps that is too radical ??

Cheers, Phil

P.S. The Object, Attribute, Presentation is I think borrowed from EDIFACT
naming conventions

TRADE/CEFACT/1999/3
Page 22
Annex B
(normative)
Rules for naming data elements and segments

B.1 Introduction
This annex contains the rules for defining structured names for UN/EDIFACT
simple data elements,
composite data elements and segments. These rules are derived from the
guidelines and principles
described in document ISO 11179-5, clause 6 (Guidelines for structured
naming conventions). In certain
instances, these guidelines have been adapted to the UN/EDIFACT environment.
In particular, the
guidelines have been extended to cover not only the naming of simple data
elements but also to cover the
naming of composite data elements and segments. The use of qualifier terms
has been modified to align
this with the use of qualifier data elements in UN/EDIFACT.
The rules are classified as:
Semantic rules rules that define how the meaning is assigned to the content
of a name.
Syntactic rules rules that define the structure of the name and the order
and occurrence of
the name components.
Lexical rules rules that define the word form and vocabulary principles that
apply to a
name and its components.
One of the fundamental principles specified in IS0 11179, and supported by
UN/EDIFACT, is that the
definition should be developed first and the name should be extracted from
it.

B.2 Semantic rules
The components of a name are: object class term, property term and
representation term.
Rule B1: The object class term shall represent the dominant area of
interest.
For example, in the names of the simple data elements:

Reference version number
Amount function code
Movement type description

Rule B2: The property term shall represent the distinguishing characteristic
or property of the
dominant area of interest. The property term shall occur naturally in the
definition.
For example, in the names of the simple data elements:

Reference version number
Amount function code
Movement type description
.
Rule B3: The representation term shall describe the form of the set of valid
data element values
for a simple data element.
For example, in the names of the simple data elements:
Reference version number
Amount function code
Movement type description

----- Original Message -----
From: "Todd Boyle" <tboyle@rosehill.net>
To: <ebxml-core@lists.ebxml.org>
Sent: Tuesday, April 17, 2001 4:23 PM
Subject: RE: Long Tags Codes etc. again


> In the DOS era, many things having long names, also had a "shortname" in
> the database so it could be printed in reports and handled on the screen.
> I guess I'm suggesting an additional Representation Type, "shortname"
which
> a core component might have.  You might call this WAPname or SMSname.  :-)
>
> I don't know whether shortnames could be generated in any systematic or
> algorithmic way.  Shortnames obviously could not be unique.
>
> Hope this helps.  Probably it doesn't...
> -Todd
>
> At 08:17 AM 4/17/2001 -0400, CRAWFORD, Mark wrote:
> >>>>
> Martin  thinks w should use the context of the previous tags to add
> meaning.  He  argues we should use size=2>  size=2><SellerParty>
> size=2><Name> size=2>  size=2>instead of <SellerPartyName> size=2>  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.    size=2>  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.
>
> martin.me.roberts@bt.com  had said
>
> One way to get round this is to use the context of the    previous tags to
> add meaning a
> <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.
>
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>