RE: SMEs : was RE: Party XML Schema Defintions

[John McClure <hypergrove@olympus.net>]

Please help me to understand this. Maybe there are alternative
implementations for what is being proposed?

1. Element-type names are represented as IDs, e.g.,
<ebxml:ABC123-456.789/>. The element-type would be XSD-concrete to
eliminate the requirement for an xsi:type attribute. So-called localized
names for the element-type are created through XSD-specified inheritance,
e.g., <enus:enusTagName/>.

I suppose this goes for attribute-type names too, e.g.,
	<ebxml:ABC123-456.789 abc987='' def654='' />

2. Element-type names are always represented in their localized form, and
the DTD or XSD identifies the identifier of the ebXML element-type it is,
e.g.,

<!ATTLIST enus:enusTagName
	ebxml:id CDATA #FIXED 'ABC123-456.789'
>

I'd appreciate knowing which, if either, of these implementations is the
consequence of going in the direction being proposed. Subsequent, I'd like
to look at this proposal from the perspective of what XSD localization
facilities already exist, for I suspect that they are indeed adequate --
you know, if they ain't broke, then why fix 'em.

As a gentle request, it might be helpful to us all if explanations of
proposals used sanctioned terms like "element-type name" rather than
"construct". I know no W3C definition for "construct".

Thanks,
John
Hypergrove Engineering, Inc.
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)

|-----Original Message-----
|From: Gregory, Arofan [mailto:arofan.gregory@commerceone.com]
|Sent: Thursday, February 08, 2001 1:12 PM
|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