|
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 -----
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
"Opportunity is what you make of
it"
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
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
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
|