[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
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]