Re: [ubl-dev] Re: [spam] Re: [ubl-dev] XPath expressions in UBL / Signatures

[Stephen D Green <stephengreenubl@gmail.com>]

Or there is the alternative of an ABIE, but for XQuery and/or XPath, so

that the backwards compatibility problem with the existing XPath BBIE

is reduced (people can reserve XPath for 1.0 (since XQuery 1.0+ uses

/ is a superset of XPath 2.0+) and the namespaces/prefixes can be

declared inline (without a need for special extra-CCTS supplementary

components).

 

Could look like this (once modelled and then incorporated into schemas):

 

 

<!-- ----------------------------------------------------- -->

<!-- UBL-CommonAggregateComponents-2 -->

<!-- ----------------------------------------------------- -->

 

<!-- ... -->

<!-- addition -->

   <xsd:element name="XmlExpression" type="XmlExpressionType"/>

 

<!-- ... -->

<!-- extension -->

   <xsd:complexType name="DocumentReferenceType">

       <xsd:sequence>

           <xsd:element maxOccurs="1" minOccurs="1" ref="cbc:ID"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:CopyIndicator"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:UUID"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:IssueDate"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:IssueTime"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:DocumentTypeCode"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:DocumentType"/>

           <xsd:element maxOccurs="unbounded" minOccurs="0" ref="cbc:XPath"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:LanguageID"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:LocaleCode"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:VersionID"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cbc:DocumentStatusCode"/>

           <xsd:element maxOccurs="unbounded" minOccurs="0" ref="cbc:DocumentDescription"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cac:Attachment"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cac:ValidityPeriod"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cac:IssuerParty"/>

           <xsd:element maxOccurs="1" minOccurs="0" ref="cac:ResultOfVerification"/>

<!-- addition -->

           <xsd:element maxOccurs="1" minOccurs="0" ref="cac:XmlExpression"/>

       </xsd:sequence>

   </xsd:complexType>

 

 

<!-- ... -->

 

<!-- addition -->

   <xsd:complexType name="XmlExpressionType">

       <xsd:sequence>

           <xsd:element maxOccurs="1" minOccurs="1" ref="cbc:XmlExpressionLanguageID"/>

           <xsd:element maxOccurs="1" minOccurs="1" ref="cbc:XmlExpressionLanguageVersionID"/>

           <xsd:element maxOccurs="unbounded" minOccurs="1" ref="cbc:XmlExpressionString"/>

       </xsd:sequence>

   </xsd:complexType>

 

<!-- alternative addition -->

   <xsd:complexType name="XmlExpressionType">

       <xsd:sequence>

           <xsd:element maxOccurs="1" minOccurs="1" ref="cbc:XmlExpressionCode"/>

           <xsd:element maxOccurs="unbounded" minOccurs="1" ref="cbc:XmlExpressionString"/>

       </xsd:sequence>

   </xsd:complexType>

 

<!-- ... -->

 

 

<!-- ---------------------------------------------- -->

<!-- UBL-CommonBasicComponents-2 -->

<!-- ---------------------------------------------- -->

 

<!-- ... -->

 

<!-- additions -->

<!-- needs specification of how to use spec URIs and version IDs for XQuery, etc here -->

 

   <xsd:element name="XmlExpressionLanguageID" type="LanguageIDType"/>

   <xsd:element name="XmlExpressionLanguageVersionID" type="VersionIDType"/>

 

<!-- alternative codified additions -->

<!-- needs a codelist, e.g. XPath2XPath1CompatibilityMode, XQuery1, XPath2, XQuery2, XPath3 ... -->

 

   <xsd:element name="XmlExpressionLanguageCode" type="XmlExpressionLanguageCodeType"/>

<!-- ... -->

   <xsd:complexType name="XmlExpressionLanguageCodeType">

       <xsd:simpleContent>

           <xsd:extension base="udt:CodeType"/>

       </xsd:simpleContent>

   </xsd:complexType>

   

<!-- ... -->

 

 

<!-- addition -->

   <xsd:element name="XmlExpressionString" type="XmlExpressionStringType"/>

 

<!-- ... -->

 

<!-- addition -->

   <xsd:complexType name="XmlExpressionStringType">

       <xsd:simpleContent>

           <xsd:extension base="udt:TextType"/>

       </xsd:simpleContent>

   </xsd:complexType>

 

<!-- ... -->

 

 

Best regards

 

Steve

----

Stephen D Green

 

 

 

On 14 May 2011 22:39, Stephen D Green <stephengreenubl@gmail.com> wrote:

> Maybe an answer is to create an XQuery BBIE as this is a

> superset of XPath and allows namespace binding - but still

> might need a version supplementary component.

>

> e.g.

>

> "declare namespace a="http://some-uri/foo/bar"; (//a:ID)[1]"

>

> This avoids backwards compatibility issues with UBL 2.0

>

> ----

> Stephen D Green

>

>

>

> On 14 May 2011 10:15, Stephen D Green <stephengreenubl@gmail.com> wrote:

>> Recognising I'm not a TC member and you guys are, so my opinion is merely that,

>> my opinion is that the qualification needed for the XPath BBIE

>> available for reuse

>> in UBL-conformant documents does have business importance, not just processor

>> relevance: It can be an essential detail of business significance in

>> resolving a ref

>> to part of a document so a human accountant might be exposed to it and

>> a technical

>> person of such a business role might in the later phases of a

>> document's life-cycle

>> have to evaluate it, just as they might have to do with codes. So it

>> does need all

>> the supplementary components necessary to make this possible at any stage in

>> a document's life-cycle (which might be decades after the XPath was 'written').

>> ----

>> Stephen D Green

>>

>>

>>

>> On 14 May 2011 09:49, Roberto Cisternino <roberto@javest.com> wrote:

>>> My comments below,

>>>

>>>> At 2011-05-14 00:02 +0200, Roberto Cisternino wrote:

>>>>>DocumentReference is an official location where UBL uses XPath, but we

>>>>>found xpath could be used in other location into a UBL document instance.

>>>>

>>>> Not in UBL 2.0 or UBL 2.1.  And what users do in extensions is up to them.

>>>

>>> I was referred expecially to the UBL Security case that I think was

>>> initially mentioned by Stephen.

>>>

>>>>

>>>>>I retain the version of xpath is a processing information not an xml

>>>>>parsing information or a business information so we could best use a

>>>>>processing instruction for providing such information without changing

>>>>> UBL

>>>>>models.

>>>>

>>>> I disagree.  There are some XPath expressions whose end result of

>>>> evaluation differs from XPath 1.0 to XPath 2.0 (which is why there

>>>> was a major version and not a minor version; though I believe that

>>>> won't be true from XPath 2.0 to XPath 3.0 as the version number is

>>>> being harmonized amongst multiple specifications).  So, someone

>>>> writing an XPath expression may be implicitly be assuming one version

>>>> or another.

>>>

>>> I can't find an explanation of this implicit assumptions on the Xpath

>>> version you mention.

>>>

>>> I proposed to use a processing instruction to indicate the XPath version

>>> used on a give document instance, just like we do for XSLT stylesheets

>>> used for rendering.

>>>

>>>>

>>>> Therefore, if the committee is going to equip users with the ability

>>>> to express version information (rather than have such simply being an

>>>> agreement between trading partners), then I feel strongly the

>>>> information has to be first-class and realized as an element.

>>>

>>> We have seen using XPath as a pointer to information, so I agree

>>> information is at the 1st position, but an XPath expression provided in a

>>> BIE is not part of the first parsing step, it is in a second or third

>>> step.

>>>

>>> It is the application that will handle that piece of XPath expression, so

>>> it will be necessary to provide the version of that xpath to allow the

>>> application to select the right xpath engine.

>>>

>>>>

>>>> I feel that a processing instruction is a second-class annotation in

>>>> an XML document.  It cannot be constrained by a document model.  It

>>>> cannot, therefore, be validated using a document model and is obliged

>>>> to be processed by an application in order to be interpreted.

>>>

>>> Exaclty, as I above explained xpath expressions are like a formula to be

>>> applied by an application at a given time.  They are evaluated after the

>>> document is parsed.

>>>

>>> Of course if we are going to provide a better xpath handling where the

>>> xpath expression will be accompained by its version, it will be better.

>>>

>>>>

>>>> Also, in an editor doing a cut-and-paste of a fragment of UBL that

>>>> includes the XPath elements is obvious and straightforward.  Where in

>>>> the content would the processing instruction be placed?  It might not

>>>> get copied if the processing instruction were not in amongst the

>>>> elements (and even then an editor might have problems with the

>>>> cutting and pasting).

>>>>

>>>> And what would be the scope of such a processing instruction?  If

>>>> there are two XPath elements in a UBL document and one of them had to

>>>> be in XPath 1.0 and the other had to be in XPath 2.0, how would the

>>>> processing instructions be used?

>>>

>>> By the ICT point of you i would discourage to mix XPath versions in the

>>> same document, it could appear to me very bizzare.

>>>

>>>>

>>>> And, finally, it would introduce a new aspect of acting on a UBL

>>>> document unlike all of the other information expressed in a UBL

>>>> document.  Thinking of our users I would weigh that heavily and

>>>> discourage introducing meaningful information in processing instructions.

>>>

>>> Sorry I still see the xpath "version" a processing instruction, so in

>>> general it is not misplaced to me.

>>>

>>>>

>>>> But, no-one has yet raised in committee that we need to qualify XPath

>>>> addresses.  Perhaps Steve or you or someone else will use the

>>>> official comment list to identify a use-case that will trigger this

>>>> discussion in committee for inclusion in an upcoming version of UBL.

>>>

>>> If XPath 1, 2 or 3 expressions can possibly return different result I

>>> beliebe we need to find a solution.  Also new XPath versions are the

>>> evidence that we need to provide an xpath version information to parsers,

>>> otherwise they will be unable to select the rigth XPath engine.

>>>

>>>>

>>>> Truthfully, I don't think we'll get a lot of uptake for XPath

>>>> addresses in UBL documents until we get applications and languages

>>>> with an eval()-like functionality.  As it stands in XSLT 2.0 and

>>>> XQuery 1.0, one cannot dynamically evaluate a string as an XPath

>>>> address ... it has to be hard coded.

>>>>

>>>> I hope this is considered helpful.

>>>>

>>>> . . . . . . . . . . . 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

>>>>

>>>>

>>>> ---------------------------------------------------------------------

>>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org

>>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org

>>>>

>>>>

>>>

>>>

>>> --

>>> * JAVEST by Roberto Cisternino

>>> *

>>> * Document Engineering Services Ltd. - Alliance Member

>>> * UBL Italian Localization SubCommittee (ITLSC), co-Chair

>>> * UBL Online Community editorial board member (ubl.xml.org)

>>> * Italian UBL Advisor

>>>

>>>  Roberto Cisternino

>>>

>>>  mobile: +39 328 2148123

>>>  skype:  roberto.cisternino.ubl-itlsc

>>>

>>> [UBL Technical Committee]

>>>    http://www.oasis-open.org/committees/ubl

>>>

>>> [UBL Online Community]

>>>    http://ubl.xml.org

>>>

>>> [UBL International Conferences]

>>>    http://www.ublconference.org

>>>

>>> [UBL Italian Localization Subcommittee]

>>>    http://www.oasis-open.org/committees/ubl-itlsc

>>>

>>> [Iniziativa divulgativa UBL Italia]

>>>    http://www.ubl-italia.org

>>>

>>>

>>>

>>> ---------------------------------------------------------------------

>>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org

>>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org

>>>

>>>

>>

>