RE: FpML-VAL solution for 559.

I’ve come in part way through this issue. Perhaps a relevant question is why model groups are being used rather than types. I think model groups as the context for rules will cause problems for XPath implementations. However it seems to me that the semantic intention of the rule in question does relate to the “context” of the model group.

I haven’t read these specs for a while, but doesn’t the context for an XPath _expression_ have to be a node in the Xpath Data Model? A model group corresponds to the term of a particle. Term and particle are not things that exist in the data model. A model group does not have existence in any of the infoset-based paradigms, including the XPath Data Model.

With respect to Matthew’s question about the use of xs:assert with model groups, look at the Schema 11-1, section 2.2.4.3 which I’ve pasted at the end of the email.

As to reasons why the current draft does not support xs:assert on model groups, I would speculate that historically there are many differences in the schema semantics of model groups versus types, some subtle, and that these raise difficulties with well-specified definition .

Some example quotes about model groups in the spec….

“Thus, model group definitions provide a replacement for some uses of XML's parameter entity facility.” “Model group definitions per se do not participate in ·validation·, but the {term} of a particle may correspond in whole or in part to a model group from a model group definition.”

It was interested to see that the scope property of the element schema component for elements declared within model groups changed from 1.0 Recommendation to 1.1 WorkingDraft. In 1.0 an element declared as part of a model group has an “absent” scope. In 1.1 it has a local scope with a parent which is the model group, i.e., basically analogous to an element declared within a type. In 1.0 I think that if 2 different model groups contain elements of the same name these have identical schema components, which is inherently confusing when considering use of these as contexts.

Regards,

Pete

Excerpt from schema 11-1 …..

Editorial Note: Priority Feedback Request

Assertions are currently only allowed to be specified in complex types. It may be deemed useful also to include assertions in named model group definitions and/or attribute groups, or even simple types. The XML Schema Working Group solicits input from implementors and users of this specification on this question.

From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On Behalf Of matthew.d.rawlings@xxxxxxxxxxxx
Sent: 16 April 2008 17:06
To: valwg@xxxxxxxx
Subject: RE: FpML-VAL solution for 559.

My reading of XSDL 1.1 is that it does not permit constraints (xs:assert) upon Model Groups: http://www.w3.org/TR/xmlschema11-1/. It isn't an easy spec to read, so would appreciate corroboration.

There must have been a good reason why the authors of XSDL didn't allow constraints upon Model Groups.

Matthew Rawlings
+44 7917 596 827

"Peter Geraghty" <Peter.Geraghty@xxxxxxxxxxxxxx>
Sent by: valwg@xxxxxxxx

16/04/2008 10:32

Please respond to
valwg@xxxxxxxx

To	<valwg@xxxxxxxx>
cc
Subject	RE: FpML-VAL solution for 559.

From a semantic viewpoint the model group is the context. Other
solutions for expressing the rule blur the semantics to facilitate
implementation.

-----Original Message-----
From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On Behalf Of Andrew Jacobs
Sent: 16 April 2008 09:47
To: valwg@xxxxxxxx
Subject: RE: FpML-VAL solution for 559.

Allowing a model group as context is my preferred solution. We are
making
increasing use of groups in the schema these days and I don't like the
idea
of explicitly listing all the occurances in the rules.

Andrew

-----Original Message-----
From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On Behalf Of
matthew.d.rawlings@xxxxxxxxxxxx
Sent: 16 April 2008 08:59
To: valwg
Subject: Re: FpML-VAL solution for 559.

Hi Christian -

I agree on your analysis. It was discussed at the VWG and I was asked to
make a proposal without using the parent or ancestor axis. That's what I
did.

In the end it doesn't buy much as the risks of using ancestor and parent
axis are of picking up nodes by accident, which is unlikely because the
xs:group contents are included by name.

The problem with making the context an xs:group is that it isn't
possible to
address it via XDM, PVSI, etc.. This isn't a barrier, just inconvenient.

Either we put the rule on the group or we enumerate everywhere the group
is
used as a context. Either choice is acceptable to me.

Matthew +44 7917596827

----- Original Message -----
From: Christian Nentwich [christian@xxxxxxxxxxxxxxxx]
Sent: 04/15/2008 11:06 PM CET
To: valwg@xxxxxxxx
Subject: Re: FpML-VAL solution for 559.

Matthew,

your solution using the sibling axis works perfectly well, but is
completely equivalent to using ".." as far as the constructs in question

are concerned (presumably we don't care much if the element is a
following or preceding sibling, and no groups allow both).

I'm not sure it will do much except ensure that the reader has to know
XPath axis syntax? At least ".." is familiar to anyone who has ever seen

a command line or URL.

As a lazy alternative, can't we just say "Context: PayerReceiver.model"
and let implementers work it out?

regards,

Christian

matthew.d.rawlings@xxxxxxxxxxxx wrote:
>
> Dear VWG Members -
>
> As requested at today's meeting I published a solution for
> http://www.fpml.org/issues/view.php?id=559 online.
>
> Matthew Rawlings
> +44 7917 596 827
> ----------------------------------------------------------------------
> --
>
> This communication is for informational purposes only. It is not
> intended as an offer or solicitation for the purchase or sale of any
> financial instrument or as an official confirmation of any
> transaction. All market prices, data and other information are not
> warranted as to completeness or accuracy and are subject to change
> without notice. Any comments or statements made herein do not
> necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
> and affiliates. This transmission may contain information that is
> privileged, confidential, legally privileged, and/or exempt from
> disclosure under applicable law. If you are not the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution, or use of the information contained herein (including
> any reliance thereon) is STRICTLY PROHIBITED. Although this
> transmission and any attachments are believed to be free of any virus
> or other defect that might affect any computer system into which it is

> received and opened, it is the responsibility of the recipient to
> ensure that it is virus free and no responsibility is accepted by
> JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable,
> for any loss or damage arising in any way from its use. If you
> received this transmission in error, please immediately contact the
> sender and destroy the material in its entirety, whether in electronic

> or hard copy format. Thank you. Please refer to
> http://www.jpmorgan.com/pages/disclosures for disclosures relating to
> UK legal entities.
>

------------------------------------------------------------------------
----
---
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html

------------------------------------------------------------------------
----
---
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html

------------------------------------------------------------------------
-------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.htmlDisclaimer:

The contents of this E-mail plus any attachment is intended for the use of the
addressee only and is confidential, proprietary and may be privileged. It will not be
binding upon Trace Group plc or any group company (Trace). Opinions, conclusions,
contractual obligations and other information in this message in so far as they relate to
the official business of Trace must be specifically confirmed in writing by Trace. If you
are not the intended recipient you must not copy this message or attachment, use or
disclose the contents to any other person, but are requested to telephone or E-mail
the sender and delete the message and any attachment from your system. Trace
takes all reasonable precautions to ensure that no virus or defect is transmitted via
this e mail, however Trace accepts no responsibility for any virus or defect that might
arise from opening this E-mail or attachments.

-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html

Disclaimer: The contents of this E-mail plus any attachment is intended for the use of the addressee only and is confidential, proprietary and may be privileged. It will not be binding upon Trace Group plc or any group company (Trace). Opinions, conclusions, contractual obligations and other information in this message in so far as they relate to the official business of Trace must be specifically confirmed in writing by Trace. If you are not the intended recipient you must not copy this message or attachment, use or disclose the contents to any other person, but are requested to telephone or E-mail the sender and delete the message and any attachment from your system. Trace takes all reasonable precautions to ensure that no virus or defect is transmitted via this e mail, however Trace accepts no responsibility for any virus or defect that might arise from opening this E-mail or attachments.