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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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


Subject: RE: [ubl] Changes to UBL NDR


Title: Changes to UBL NDR
Hi Peter,
 
> I though that this reluctance was cleared away in the last Atlantic call.
 
Unfortunately, I was unable to make last week's call.
 
As you may recall, when this was first proposed I thought it was a good idea and supported it fully. It was only after members with significant standards experience expressed reservations that I became ambivalent. If the Danish proposal now has the support of these members (which it seems to have), I have absolutely no objection to its adoption with some minor changes and clarifications, proposed in previous emails, to be discussed today.
 
Thanks,
Mike
 


From: Peter Borresen [mailto:PLB@itst.dk]
Sent: Wednesday, 05 April 2006 0431
To: Grimley Michael J NPRI; ubl@lists.oasis-open.org
Subject: SV: [ubl] Changes to UBL NDR

Hi Mike
 
I though that this reluctance was cleared away in the last Atlantic call. I understand your worry but in my suggestion the use of xsd:any is very restricted and is after all a bette suggestion than putting extensions into a CDATA construction in a note field, that we see a lot of today. A text field is after all just as undefined (if not more) that a xsd:any.
 
We a problem with implementing the proposal in our own localization: How can we do a localization that does not follow the UBL NDR? Can we then call that UBL? Is it desireable for UBL that the largest implementation of UBL will not be UBL?
 
I agree with you that we should discuss this at the meeting today. We also need to discuss whether we want documents to be exchange within the UBL namespace or only within a derived namespace. If the UBL namspace is going to be used for the real world then UBL must listen to the requirement from the real world and not just let it be up to the implementors.

 Kind regards

Peter

 

-----Oprindelig meddelelse-----
Fra: Grimley Michael J NPRI [mailto:GrimleyMJ@Npt.NUWC.Navy.Mil]
Sendt: 4. april 2006 22:30
Til: ubl@lists.oasis-open.org
Cc: Peter Borresen
Emne: RE: [ubl] Changes to UBL NDR

Peter,
 
I believe there is still significant reluctance to allow xsd:any in the UBL Standard. Issues were raised in New York that I'm not sure have been addressed. Have you considered my suggestion of implementing it as a Danish extension to UBL, rather than it becoming a part of the UBL standard?
 
Hopefully all interested parties will be on the call tomorrow so we can reach closure on this issue.
 
As far as including additional information in a message, I believe that would be a Content issue, rather than an NDR issue (aside from the fact that they would need to be elements, rather than attributes).
 
Thank You,
Mike
 


From: Peter Borresen [mailto:PLB@itst.dk]
Sent: Tuesday, 04 April 2006 0847
To: ubl@lists.oasis-open.org
Subject: [ubl] Changes to UBL NDR

Dear UBL TC

Here is my proposal for updating the NDR so it fits with the Danish requirements:
------------------------------------------------------------------------------
Chapter 5:

Delete line 1583-1589   [This is allready described in line 1790-1798]
Change line 1790-1798 to:

"UBL restricts use of xsd:any to extensions. There can only be two usages of xsd:any in a document; one in the end of a line element and one as the last element of the document. The content of a xsd:any must point to a well known schema, approved by the UBL TC, UBL subcommitee or a UBL localization group."

Chapter 8:

Add a new section 8.5 (Section 8.5 becomes 8.6) :

8.5 Instance origin

To be able to track how the instance was generated the following process-instruction SHOULD be added to each document instances:

<?InstanceInfo
        Creator="<person or application (inklusiv full verison attributes) that has generated the document"
        Created="<date and time the document was send>"
?>

To be able to track what version of schemas an instance was generated from the following attributes SHOULD be present in each document:

  • MinorVersion
  • Context
  • Subset
  • Profile

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

Kind regards

Peter

PS: Maybe some one english speking person should edit the text before chunking it into the NDR document.



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