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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: Re: [regrep] Implementing CCTS in Registry - further thoughts


I know that, I was just teasing Duane :-)

Farrukh Najmi wrote:

> From an ebXML Registry stand point the more significant attribute is 
> the objectType which can be anything at all by extending the canonical 
> ObjectType ClassificationScheme. This should be defined by the CCTS 
> team as part of their spec and we should help them as needed.
>
> The CCTS spec should have a section that defines a normative binding 
> to ebXML Registry specification where things like objectType for a CC 
> would go.
>
> mimeType comes into play more when you wish to render the content for 
> example in a browser environment using browser-based plug-ins.
>
> Matthew MacKenzie wrote:
>
>> Duane --> what's the obsession with a mime/type?
>>
>> How about:
>>
>> application/x-uml-diagram
>>
>> ;-p
>>
>>
>>
>> Duane Nickull wrote:
>>
>>>
>>>
>>> David RR Webber - XML ebusiness wrote:
>>>
>>>> Duane,
>>>>
>>>> The XML Global Registry interface already does all this - see
>>>> the attached GIF - where the MIMEtype = XML...<SNIP>
>>>
>>>
>>>
>>> >>>>>>>>>>>
>>> David et al:
>>>
>>> If the MIME type was XML, then yes - that would work.  There is 
>>> currently no MIME type specified for any represenation of Core 
>>> Components or BIE's.  If it is to be XML, then let's get the work 
>>> done and specify that so developers can move on.
>>>
>>> UML is NOT a MIME type.
>>>
>>> >I do not see that we have to wait until someone officially
>>> >says we can represent a corecomponent in XML - is
>>> >there some kind of CEFACT CC police or something?!?
>>> >>>>
>>> You should see the size of the file they have on you!
>>>
>>>  ;-)
>>>
>>> Kidding aside,  implementors like us are holding off so we don;t 
>>> throw money down a rathole developing support for something that 
>>> could change at any time.  If we assume it is XML and write code for 
>>> that, then we all decide to use ASN1, we are left in the lurch.
>>>
>>> Duane
>>>
>>>
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



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


Powered by eList eXpress LLC