[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]
Powered by eList eXpress LLC