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: [ubl-dev] Q: What mime type for UBL/ebxml with smtp ?



Also, you might check out RFC 3023 - XML Media Types (I think this is
the latest version), which might favor creating a pattern such as:

application/uml-TRANSACTIONID+xml,

with TRANSACTIONID replaced by all the distinct types of UML documents
that need to be distinguished. That is, assuming you want a distinct
MIME type for each business document type. Otherwise, maybe use 

application/uml+xml

for a generic uml type.

MIME media types have a multiple personality disorder. Sometimes they
just indicate a broad syntactical type of data (like
application/edifact) which is mostly useless in dispatching
to a specific final application. Sometimes they indicate specific
applications of a vender,
like application/msword or application/vnd.*. Sometimes they indicate a
datatype that can be handled by many apps (image/jpeg). 

If you glance over the media type list at IANA, 
http://www.isi.edu/in-notes/iana/assignments/media-types/media-types
there does not seem to be a unifying semantic basis for how the subtypes
work,
or even what functionality the subtypes are to support. 

One thing that probably won't fly is creating a new toplevel
content-type like
"text" "application" "multipart" "message" "image" because these major
categories
have a lot of well-entrenched inertia.

A way to proceed might be to pick a standard main content-type and focus
on what needs you want the content-subtypes to meet. For example, maybe
application dispatch is solved some other way, and so cluttering up the
media type namespace with a lot of special subtypes is unnecessary.








ok - fair enough for text/xml. I'm just canvassing thoughts, just as you
are. I can see the logic behind your reasoning. 

But I think there's also a case for something more specific like
ebxml/Order as every ebxml/Order would be xml by definition anyway
without exception.

IE seems to pick up any text/xml document by default on most systems.
But I would suggest that it doesn't have anything in it to be able to do
anything with the document other than change the colors and fonts of the
letters.

This isn't really the "correct" handling of a UBL/Invoice and far from
the requirements of any business that I have seen. 

What needs to happen with a UBL invoice in most places is that it needs
to be formatted properly, validated,  and interpreted in context with
all the other UBL/Invoices from the Selling Party. A bit more than what
IE or any other Browser can currently offer.

Anyway, these are just my personal opinions. Obviously in my test
programs I'll make sure that I provide support for text/xml and many
thanks for pointing it out. I still think ebxml/Order or UBL/Invoice
scheme would be better.....

anyway.. best regards

David


Quoting stephen_green@seventhproject.co.uk:

> 
> David
> 
> I should think there would be a general feeling against
> any mime type other than text/xml
> 
> I wonder how XPath 2.0 and XSLT 2.0 might help here with e-mails 
> (might support for non-xml text allow pulling in of 
> documents/fragments from emails in a folder - for Java type 
> e-mails,etc - where these are  just held as text files in a folder? - 
> not much help perhaps if the messages are held in a database such as a

> .dbx file perhaps)
> 
> As for OrderResponse I'd say (XPath) 
> /Order/AcknowledgementResponseCode
> is what you want (valid values are 'OrderResponse' and
> 'OrderResponseSimple')
> 
> All the best
> 
> Stephen Green
> 
> 
> david.lyon@computergrid.net wrote on 12.08.2004, 05:01:26:
> > 
> > Anybody,
> > 
> > I know the answer is probably rtfm/stupid but I thought I'd just 
> > check with
> any
> > experts first as they might know an answer off the top of their 
> > heads.
> > 
> > Just trying to put together some ubl test data and I want to pull in

> > UBL acknowledgements with a mail utility from a pop mailbox. no 
> > probs in
> that..
> > 
> > but is there a mime type for UBL yet?
> > 
> > or is the best way just to stick all the acknowledgment documents in

> > a
> directory
> > with some kind of xpath and go from there?
> > 
> > Then, anybody know how to quickly determine the document type for an

> > acknowledgement? say an OrderResponse.
> > 
> > My preference for an answer would be XPath/Perl, but any other 
> > language
> would
> > probably do.
> > 
> > only about 113,000 unique xpath elements to deal with; so little 
> > time to test them all
> > 
> > David
> > 
> >  
> > 
> > -------------------------------------------------------
> 




-------------------------------------------------------



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