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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: Re: [ubl-ndrsc] RE: Core Components


It's a very good question, and you may recall that it came up in a small 
way in Burlington.  (We had been talking about the fact that there's an 
essential mismatch between Numeric. Type and the XSD numeric simple 
types -- that is, if you simplistically map Numeric. Type to a *single* 
base XSD type, you miss an opportunity for data validation of the type 
you refer to below.  At the time we said "We're leaning towards not 
defining CCTS-based equivalents for all of the number-related built-in 
types.")

My feeling is that this is one of the issues that has to be decided as 
part of our "CCT module handcrafting" exercise, which we began in 
Burlington but on which we have *much* more to do.  Really we should 
think of it as "common leaf types module handcrafting", and probably we 
need to leave an explicit safety valve for using XSD built-in types 
directly.

	Eve

CRAWFORD, Mark wrote:
> Garret has asked me the following question -
>  
>> We have been struggling with CCTs and Data Types over the past couple 
> of weeks and have come across several situations where CCTs do not 
> appear to > provide enough flexibility.  For example, we were trying to 
> define some of the XML Schema data types as CCTS data types and got 
> stuck at anyURI.  This > XML Schema data type does not fit very well 
> into the list of approved CCTs.  We also came across a few instances 
> where a proposed data type would be > better represented as a simple 
> string rather than a Text CCT with an associated Language. Identifier. 
> Are there any recommendations about how to represent > XML Schema data 
> types in CCTS syntax? 
> My initial reaction  is that we would not expect a one to one 
> relationship as CCT data types are not syntax dependant.  However this 
> answer leaves me cold.  My next reaction was to reply that since anyURI 
> is a type of string, then simply use Text. Type.  However this looses 
> the ability to do data type validation against the xxxx://.  My next 
> reaction was that the syntax binding of CCT data types would be 
> accomplished by the constraints language, but I am not sure that the 
> Attribute Construct is adequate.  So I turned to the UBL NDR document 
> with no satisfaction and finally to the Definition of Elements, 
> Attributes, and Types - still no resolution.  So it seems, unless I am 
> missing something, that we have not determined if or how we are going to 
> directly associate XSD built-in or user-defined data types with CCT data 
> types.  Any comments?
>  
> Mark

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                     NEW!!! cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com



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


Powered by eList eXpress LLC