|
Mark
What i
dont understand with your philosophy is that you end up with a BSR type
construct which in the extreme (and if its not the extreme, how do you define
the limits of the two approaches) of:
<order_confirmed_delivery_address_street_number/>.
and not only that you will have further constructs of <invoice_confirmed_delivery_address_street_number/>,
<invoice_confirmed_delivery_address_street_address/>
and every possible combination which will result in massive maintenance issues
as well as user confusion and
complexity
...and
bearing in mind the potential complexity of most messages this is a simple
example.
I would argue strongly that the approach of the nesting
of semantic components is asserting exactly the purpose of the nest constructs
in XML in the first place. It will also significantly ease
maintenance. Maybe i missed some of this thread but apart from saying
'needlessly magnify the complexity' i see little evidence to back your
statement. Yes, it does result in dispersed semantics around the nesting
of a document but is not visually nor programmatically difficult to run a
routine which makes order_confirmed_delivery_address_street_number from
<order><confirmed><delivery><address><street><number>
Regards
STUART
Technical Strategy Director, Technical Strategy
Team
Business Development
Unit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart
Campbell
TIE Holding
NV
UK T:+44 1270
254019 F:+44 7971 121013
Netherlands T:+31 20 658
9335 F:+31 20 658 9901
Global
M:+44 7970 429251
E:stuart.campbell@TIEGlobal.com
W:www.TIEglobal.com
P:www.stuartcampbell.co.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
|