RE: SMEs : was RE: Party XML Schema Defintions

[martin.me.roberts@bt.com]

Dear all,
	The data seperation from UI is good but I get a bit worried when you
end up with IDs being the main way of distinguishing an construct.  Would
these be numbers? who would issue them? etc become issue.  If however you
said that the ID was the initial semantic bearing name such as ( at this
point I dive into semantic soup and drown! perhaps ID are a good idea after
all.!!!:)

Martin M.E. Roberts
xml designer, BTexaCT
01473 643775
martin.me.roberts@bt.com


-----Original Message-----
From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
Sent: 08 February 2001 21:12
To: 'Joaquin Miller'; ebxml-core@lists.ebxml.org
Subject: RE: SMEs : was RE: Party XML Schema Defintions


Folks:
 
At the Orlando meeting, Harmut suggested that we have non-semantic-bearing
IDs for each construct, and then "official", language-specific
human-readable tags for each language, with an English-language version
being one of the first outputs, but with others constrcuted along the same
lines. This approach lets you build applications to either the unique IDs
(for multi-language support) or to build applications that support only a
single, language-specific version. Presumably, the human-readable tags would
have their own consistent rules about providing names, but these rules
themselves might be prone to localization(!)
 
This is a good, flexible approach that would seem to offer the most in terms
of handling localization problems, and I suggest we follow it.
 
(Harmut - sorry if I have mangled your suggestion - if I am wrong, please
feel free to correct).
 
Cheers,
 
Arofan Gregory

-----Original Message-----
From: Joaquin Miller [mailto:miller@joaquin.net]
Sent: Thursday, February 08, 2001 12:48 PM
To: ebxml-core@lists.ebxml.org
Subject: RE: SMEs : was RE: Party XML Schema Defintions


At 12:09 PM 2/8/2001 -0800, Hayes, Brian wrote:


It is general considered to be good architecture to seperate user interface
issues from data issues: Your user friendly user interface sould not be
displaying XML tag and attribute names.


Absolutely!  I could not agree more.

It's why i wrote: "Everyone can use software to display the data with field
names they can read and to provide explanations for what those field names
mean."

I side with those who suggest using identifiers.  I feel it is a much better
way than hanging our hat on natural language tags, whether English or
so-called "Foreign."  I don't want to repeat here all the traffic about the
problems with dependence on exclusive use of natural language tags.




-----Original Message-----
From: Joaquin Miller [ mailto:miller@joaquin.net <mailto:miller@joaquin.net>
]
STEPHENIE COOPER wrote:

ebXML's goal should be to help make that happen.

Yes.  Let's go for the whole planet.  Not just our company's customers or
partners.  And let's go for the people who speak Foreign, too.  Everyone can
use software to display the data with field names they can read and to
provide explanations for what those field names mean.  There has been a lot
of recent eMail traffic about how to define ebXML in order to make that easy
for everyone.  Let's do it.



Cordially,

Joaquin 

................................................
Joaquin Miller
Chief Architect
Financial Systems Architects

mailto:joaquin@acm.org <mailto:joaquin@acm.org> 

San Francisco
phone: +1 (510) 336-2545
fax:   +1 (510) 336-2546
PGP Fingerprint:
CA23 6BCA ACAB 6006 E3C3 0E79 2122 94B4 E5FD 42C3