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] Bill&Eve's proposal on local/global elements


Mike Rawlins makes the comment that we should not "invent" new RTs, since
then we won't be ebXML-compliant. While I appreciate what he is saying, i
would like to point out sonme cases where the RTs we have been given are

(1) Duration - this is a primitive type in the XSD datatypes we are using,
and it has a lot of business use. If, for example, I need to express a shelf
life, then I need to express this as a suration, since I may not know when
specific perishable goods will be delivered (the start date) or I may be
using the duratiuon as a pure descriptior.

(2) URL/URI/URN - while this is really just a type of address, it is a
priviledged sort that is treated specially. Especially in the case of URLs,
we will need to be able to identofy and resolve these. I would suggest that
this needs to be an RT, although perhaps this is simply a matter of binding
and can be left in that space. Common use of this is with attachments, which
brings me to my next point...

(3) "Graphic" as suggested by the CC spec is unworkable. You very rarely put
graphics inline in business documents - typically, you specify what they are
called from the computers' point of view (a URL - that is, a file name -
pointing into your multipart MIME or whatever, and some descriptive text
explaining what the purpose of the graphic is - a logo, a CAD image, etc. It
is polite also to describe the format of the graphic.)

(4) "Prose" - as Eve mentioned in our discussion of mixed content, this is a
distinct type of content that is not common in business documents, but does
need to be accomodated where it does occur. 

Perhaps we can submit these as comments to the CC spec, and get them fixed
next week in Seattle. However, we need for our own purposes to get a
workable system, and should not be too hampered by a specification that has
not been widely implemented. It seems to me that we should be able to get
our fedback into the CC group through common membership. Certainly, Mark,
Gunther, and myself are active in the CC group, and I believe that we should
be able to raise these points and get a positive response.



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

Powered by eList eXpress LLC