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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Re: Global elements doing UBL a disservice


Ken,

Hi, I think Stephen had given me some help on understanding more
about the extensibility discussed in Joseph Chiusano's example,
that it was more on the simple type extensions and restrictions, 
and so impacts on how CCTS was to be implemented and observed
at the same time, versus the extension points that are to be
sited within complex types that you've keenly worked on (or
are keenly working on).   So perhaps there's no conflict in what
we're talking about.

Help me understand here, but I didn't see how the discussions of 
Stephen and Joseph and others like David, Fraser, Fulton and perhaps
others I've not mentioned, had concluded beyond reasonable doubts 
(sorry, watching too much of Boston Legal... :)  that it is clear 
that W3C Schema features are not sufficient to the task, as you've 
put it.   It's not so clear to me at least.  How did the conclusion
get drawn?  What exactly was the requirement and in what way is W3C
schema inferior to meeting that requirement?

It would be a rather surprising conclusion to draw, that UBL
requirements are so high that W3C Schema cannot meet the kinds 
of requirements to describe the desired data sets.  If so, what more
would be needed of the expenses on getting the right software, testing
for the correct implementation, and the bottom line, allowing more
people (including SMEs) to use UBL?   Of course, if we design UBL
schemas in a way that requires precisely what W3C schema cannot
possibly offer, the question, if we allow for simplicity and
compactness, then becomes, can the same set of data instances
desired by UBL be described with only those facilities offered 
by W3C schema?

Anyway, back to the thread's subject, it would also seem that for 
the xsd:any mechanism you're developing, the same mechanism could 
go under global or local type declarations.

I certainly hope we're not at the juncture of seeing the emergence
of requirements for other additional data description languages in
UBL 2.0.  That might be too fast, too soon.... 



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6820-2979
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Fri, 19 May 2006, G. Ken Holman wrote:

>>At 2006-05-19 16:55 +0800, Chin Chee-Kai wrote:
>>>On schema extensibility, end-users defer extensions to developers
>>>and implementors, who then seek compatible ways to implement those
>>>business extensions.
>>
>>Fine ...
>>
>>>Schema has a couple of ways to allow that.
>>
>>But with the recent efforts of Steve and Joe to demonstrate on this
>>list any extensibility using W3C Schema features, I think it is clear
>>the features are not sufficient to the task.
>>
>>If developers and implementers implemented the business extensions
>>solely within the new extension point being provided in the next
>>draft UBL 2 then there (1) won't be a need to shoehorn insufficient
>>validation facilities and (2) implementations will be true to the
>>compatibility measurement with UBL 2 because all instances will
>>continue to validate according to the normative UBL 2 schemas
>>regardless of the embedded extensions.
>>
>>I feel this compatibility test will promote interoperability and I
>>believe these benefits will outweigh possible implementation concerns.
>>
>>. . . . . . Ken
>>




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