[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Re: [spam] Re: [ubl-dev] XPath expressions in UBL / Signatures
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 >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]