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] Minutes of Atlantic UBL TC call 8 September 2010

At 2010-09-12 17:45 -0400, Jon Bosak wrote:
>    JB: The W3C schema validation limitation on multiple extensions
>    argues for putting the XAdES mechanism in the UBL document
>    schemas themselves.  This should be thought about in the PRD1
>    review cycle.  What are the main reasons for implementing
>    advanced digital signatures as an extension?
>    GKH: There are two:
>    1. We can apply the same extension framework to 2.0 schemas as
>       well by just copying in the different extension content.
>    2. XAdES solves digital signatures for Europe, but users in
>       other communities may want to specify something different.

Which, perhaps, indicates we are being too bold to call the apex 
element generically as "sig:UBLSignatures" instead of more 
specifically "sig:XAdESSignatures".  I think this will be one of my 
items of feedback for PRD2.

>    To be resolved in PRD2.

Other reasons I've been thinking of that didn't come to mind when 
asked during the call:

3. Its structure provides an ideal model for designers of extensions to follow.

4. These signature objects are not business objects but very specific 
"implementation" objects.  They are related to the signature business 
objects in the common library (hence the reference), but an XAdES 
profile of the W3C digital signature vocabulary *isn't* a business 
object.  Until now most of the objects in the common library are 
business objects or *generic* implementation objects, not *specific* 
implementation objects.

5. The isolation of the signature stuff in its own set of namespaces 
allows it to be easily elided from an instance (as is true for all 
extensions).  On the other hand, it also allows signature information 
to be added after the document has been completed without venturing 
into and changing the business objects of the instance.  This 
promotes an isolation of software such that the signature software 
doesn't need to know about the business objects (though of course it 
has to know about extension objects, so it isn't entirely oblivious).

When I think of others, I'll post again to add to the list.

. . . . . . . . . . Ken

XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

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