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] XPath expressions in UBL / Signatures


At 2011-05-13 13:38 +0100, Stephen D Green wrote:
>Like Roberto, I think, agreed, maybe a future BBIE could be defined 
>to cover the need for all the explicit information about an XPath 
>expression such as bindings and versions (and maybe modes such as 
>1.0 compatibility mode) so that any future understanding of the 
>document (e.g. by third parties such as accountants and governmental 
>auditors, etc) would be unambiguous, much as there is for codelists 
>- probably just needs a qualified datatype with suitable 
>supplementary components.

Indeed.  An optional supplementary component for the default 
namespace (absent implies no namespace) and then the XML in-scope 
declarations for prefixed namespaces would be definitive.  Perhaps 
another optional component indicating the assumed version of XPath 
library and syntax support (absent implies 1.0).

I see the XPath element is currently based on the CCTS text type:

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#t-CommonLibrary-629

It is technically possible, then, to create an XPath unqualified data 
type in this module:

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/xsd/common/UBL-UnqualifiedDataTypes-2.1.xsd

... that extends the CCTS text type and adds the supplemental 
components desired as attributes.

It would be backward compatible with the XPath BBIE in UBL 2.x 
documents, but I would still be reluctant to add it this way to UBL 
2.y because it would be the first unqualified type that would not be 
compatible with other CCTS-based documents whose business objects are 
based on the standard CCTS types.  Systems supporting those documents 
would not know what to do with the introduced supplemental components.

As it stands today, there are no attributes in UBL that are not in 
CCTS 2.01.  I'm uneasy about suggesting changing that.

Making a UBL ABIE with the required components would ensure all 
components are based on standard CCTS types, but it wouldn't be 
backward compatible with the UBL 2.0 BBIE.  Hmmmmm ... unless we 
added these needed components as BBIEs as siblings to the XPath 
element in DocumentReference, since XPath is only used in 
DocumentReference and nowhere else (but would require the same 
multiple BBIEs anywhere new where XPath is introduced in an ABIE):

http://docs.oasis-open.org/ubl/prd1-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#d-CommonLibrary-629

Anyway, let's look at this when the committee gets a compelling use 
case.  That use case would drive one of the two above approaches, or 
indeed maybe a third.

I hope this helps.

. . . . . . . . . . . Ken

--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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