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

["Roberto Cisternino" <roberto@javest.com>]

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