OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: SMEs : was RE: Party XML Schema Defintions


|Dear all,
|
|it seems that we all are in agreement to support language neutral
|constructs
|to identify ebXML components (including aggregates). They would allow to
|cross reference ebXML human readable tags in whatever language. Another
|benefit could be the mapping with interfaches of applications and/or with
|other former or future eb relevant standards (ANSI X12, EDIFACT, ...).
|

Folks,
I am still having trouble understanding exactly what you are proposing.
Here is a resend of the 2/9 note I sent (yet to receive any response). If
the note is way off base, it'd be fine to tell me so. If it's not clear in
its explanation of the two alternative implementations, then tell me so,
and I will try to clarify it. Or tell of other alternatives you have in
mind.
Thanks!
John
=============================================
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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC