<br><font size=2 face="sans-serif">Hi Dave</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the write up. A couple of
comments before today's call:</font>
<br>
<br><font size=2 face="sans-serif">First off I've remembered one of the
reasons that we decided not to use the XDM directly. It was to do with
the range of characters supported by XML versus DFDL. We need our infoset
to be capable of holding x'00' for example.</font>
<br>
<br><font size=2 face="sans-serif">The next two statements indicate most
clearly the problem I see with the proposal as worded:</font>
<br><font size=2 face="sans-serif">- "</font><font size=2 face="Calibri">The
DFDL Data Model supports all of the nodes types in the XDM</font><font size=2 face="sans-serif">"
- no it does not, it only covers those that it actually needs.</font>
<br><font size=2 face="sans-serif">- "</font><font size=2 face="Calibri">All
other XDM nodes may be provided by a given DFDL implementation </font><font size=2 face="sans-serif">"
- no they should not. They can be provided, sure, but not by a DFDL
implementation.</font>
<br>
<br><font size=2 face="sans-serif">I think you are falling into the same
trap that we could have fallen into when adopting XSDL as the basis for
DFDL. The spec makes it very clear that a DFDL Schema uses an explicit
subset of XML Schema, and that, for example, an XML Schema that contains
attributes can not be a valid DFDL Schema. Not even if the attributes are
un-annotated. Any mapping of DFDL output to XML is a separate exercise.
The same must be true for the DFDL Infoset - it can use XDM as the
basis but that's as far as the statement should go. What we have
to weigh up is whether taking a subset of XDM, plus extending it to handle
x'00', unresolved choice nodes, etc, makes the DFDL Infoset easier for
users to consume, or whether we are better off with a separate model. </font>
<br>
<br><font size=2 face="sans-serif">Overall, I think you are tailoring the
DFDL infoset to your end goal of XML compatibility and I don't think that
is the correct approach. </font>
<br>
<br><font size=2 face="sans-serif">I don't think we should discuss use
of XML Infoset or PSVI at all. Again, that is a transformation to
XML and beyond the scope of the spec. If a user wants to see how that interops
with XDM, he can use the XDM spec.</font>
<br>
<br><font size=2 face="sans-serif">Regards<br>
<br>
Steve Hanson<br>
Programming Model Architect<br>
WebSphere Message Brokers<br>
Hursley, UK<br>
Internet: smh@uk.ibm.com<br>
Phone (+44)/(0) 1962-815848</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Mike Beckerle"
<mbeckerle.dfdl@gmail.com></b> </font>
<p><font size=1 face="sans-serif">12/05/2009 14:45</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
<mbeckerle.dfdl@gmail.com></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">"'Dave Glick'" <dglick@dracorp.com>,
Steve Hanson/UK/IBM@IBMGB</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif"><dfdl-wg@ogf.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">RE: [DFDL-WG] DFDL Data Model Recommendations</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3> </font>
<br><font size=2 color=blue face="Arial">Augmented infoset does not contain
things like all branches of choice. </font>
<br><font size=3> </font>
<br><font size=2 color=blue face="Arial">Augmented infoset contains the
hidden nodes. Regular infoset lacks hidden nodes. Example, hidden element
holds number of occurrances of a recurring element later in the bit stream.
Logically this hidden element isn't there. But expressions need to refer
to its value, so it has to be in "some" infoset, so we call that
the augmented infoset. Another thing that will often be hidden are the
elements used to discriminate arms of choices. These "tags" are
almost never going to want to show through into the logical data model,
as XML tags everything so explicitly, that having additional tags around
is nothing but clumsy. These additional nodes in the augmented infoset
are used both in parsing and unparsing.</font>
<br><font size=3> </font>
<br><font size=2 color=blue face="Arial">Re: unparsing invalid models.
</font>
<br><font size=3> </font>
<br><font size=2 color=blue face="Arial">We perhaps need another term,
but the augmented infoset also gets default processing done on it. This
allows an invalid infoset to be unparsed because certain logic will be
used to make it valid. This logic is the filling in (augmenting the infoset)
of default values (only!). E.g., if an element has a default value, or
fixed value, and is required, but is not in the infoset, then it will be
automatically added to make the resulting infoset valid. </font>
<br><font size=3> </font>
<br><font size=2 color=blue face="Arial">Similarly, if an element has an
outputValueCalc property, then it is not expected to be found in the infoset.
Rather, on unparsing, the calculation is performed and the infoset node
created as an augmentation to the prior infoset.</font>
<br><font size=3> </font>
<br><font size=2 color=blue face="Arial">The values used when unparsing
must be well formed for their corresponding types, and representable by
those types, but they do not need to be valid in the sense of being within
a numeric range constraint, or obeying a regular expression pattern as
expressed on the XSD. </font>
<br><font size=3> </font>
<br><font size=2 color=blue face="Arial">So we do work to fill in defaultable
values and thereby make an infoset "more valid" than it was,
but we don't generally require XML-style validity.</font>
<br><font size=3> </font>
<br><font size=2 color=blue face="Arial">...mike</font>
<br><font size=3> </font>
<br><font size=3> </font>
<br><font size=3> </font>
<p><font size=2 color=#000080 face="Arial"><b>Mike Beckerle | OGF DFDL
WG Co-Chair | CTO | Oco, Inc.</b></font><font size=2 color=#808080 face="Arial"><br>
Tel: 781-810-2125 | 100 Fifth Ave., 4th Floor, Waltham MA 02451
|</font><font size=3 face="Times New Roman"> </font><a href=mailto:mbeckerle.dfdl@gmail.com><font size=2 color=#808080 face="Arial"><u>mbeckerle.dfdl@gmail.com</u></font></a><font size=2 color=#808080 face="Arial">
</font>
<p><font size=3> </font>
<br>
<br>
<hr><font size=2 face="Tahoma"><b>From:</b> dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org]
<b>On Behalf Of </b>Dave Glick<b><br>
Sent:</b> Monday, May 11, 2009 8:22 PM<b><br>
To:</b> Steve Hanson<b><br>
Cc:</b> dfdl-wg@ogf.org<b><br>
Subject:</b> [DFDL-WG] DFDL Data Model Recommendations</font><font size=3><br>
</font>
<br><font size=2 color=#004080 face="Calibri">All,</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">I have attached my first
draft of recommendations for the DFDL Data Model. It is based heavily on
XDM and should be mostly compatible. Where there are incompatibilities,
they are by convention and not related to the actual representation so
I believe a system that is set up to work with XDM should be easily adaptable
to work with DFDL. This was important to me – in my project I would be
using DFDL as part of a pipeline process that also involved transforming
the results of parsing using XSLT and then unparsing the results of transformation.
I imagine many other potential users of DFDL will be engaging in similar
XML pipeline scenarios. In these situations, the closer the DFDL model
is to those used by other XML technologies, the better. Hopefully the recommendation
meets the requirements Steve mentions below – it turns out most of the
existing infoset could be mapped directly to XDM concepts. I introduced
a new node type for the unresolvable concept to match the existing infoset,
but discuss how it is related to XDM and other XML technologies.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">This exercise brought to
major questions to mind:</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">- Must an instance of the
XML Infoset (and XML document) be valid against a given DFDL Schema (as
determined by an XML Schema validation engine) to be available for unparsing?
If not, is it up to the DFDL implementation to determine the suitability
of the XML Infoset Character Information Items for their given unparsed
data type? The real question is: for the unparsing process can a DFDL Data
Model be constructed from an XML Infoset directly or only from a PVSI (where
does the data for unparsing really come from)? It would seem to me that
if the input XML isn't valid against the DFDL Schema, then it probably
can't be unparsable - otherwise, how would the invalid portions be handled
(such as strings that should be numeric or a structure that doesn't match)?</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">- I am confused by the notion
of the "augmented infoset". The regular infoset appears to be
based on the logical structure of the data post-parsing. In other words,
choices are resolved and the result looks something like an XML Infoset,
PSVI, or XDM tree might following something like XSLT transformation. The
augmented infoset on the other hand appears to be based on the logical
structure of the DFDL Schema being used for processing and therefore contains
branches for all choice possibilities, etc. It is "filled in"
as parsing takes place. This doesn't make a lot of sense to me - what about
the branches for which there was no data to "fill-in" (such as
choice branches that weren't followed)? Are they dropped following parsing?
If not, then there are a lot of information items in the final tree that
have no value. It made more sense to me to consider the DFDL Data Model
as being constructed during parsing and at any given time in the parsing
process a portion of the model (that which has already been parsed) is
available.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">Hopefully those questions
made sense... I should (finally) be on the call this Wednesday to discuss.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">Dave</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 face="Tahoma"><b>From:</b> Steve Hanson [mailto:smh@uk.ibm.com]
<b><br>
Sent:</b> Wednesday, May 06, 2009 11:15 AM<b><br>
To:</b> Dave Glick<b><br>
Cc:</b> Alan Powell; dfdl-wg@ogf.org<b><br>
Subject:</b> Re: [DFDL-WG] Agenda for OGF WG call 6 May 2009</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Arial"><br>
Dave</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
Two intents of the infoset was that it should be a) simple and b) easily
related to the grammar in 11.3, so whatever you come up with needs to take
those requirements into account.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
"</font><font size=2 face="Tahoma">Parts of XDM that have no relevance
to DFDL but are also not conflicting should probably be left in for conciseness
and compatibility.</font><font size=2 face="Arial">" - a) above would
imply the opposite.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
The XDM spec defines the rules for how an XDM can be created from an XML
Infoset or a PSVI. We can do a similar exercise for DFDL Infoset,
for those users who want to use XSL for any post-DFDL transformation.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
Regards<br>
<br>
Steve Hanson<br>
Programming Model Architect<br>
WebSphere Message Brokers<br>
Hursley, UK<br>
Internet: smh@uk.ibm.com<br>
Phone (+44)/(0) 1962-815848</font><font size=3 face="Times New Roman">
<br>
</font>
<p>
<table width=100%>
<tr valign=top>
<td width=33%><font size=1 face="Arial"><b>Dave Glick <dglick@dracorp.com></b>
<br>
Sent by: dfdl-wg-bounces@ogf.org</font><font size=3 face="Times New Roman">
</font>
<p><font size=1 face="Arial">06/05/2009 13:55</font><font size=3 face="Times New Roman">
</font>
<td width=66%>
<br>
<table width=100%>
<tr valign=top>
<td width=9%>
<div align=right><font size=1 face="Arial">To</font></div>
<td width=90%><font size=1 face="Arial">Alan Powell/UK/IBM@IBMGB, "dfdl-wg@ogf.org"
<dfdl-wg@ogf.org></font><font size=3 face="Times New Roman"> </font>
<tr valign=top>
<td>
<div align=right><font size=1 face="Arial">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="Arial">Subject</font></div>
<td><font size=1 face="Arial">Re: [DFDL-WG] Agenda for OGF WG call 6 May
2009</font></table>
<br><font size=3 face="Times New Roman"> </font>
<p>
<br>
<table width=100%>
<tr valign=top>
<td width=50%>
<td width=50%></table>
<br></table>
<br><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 face="Tahoma"><br>
All,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Tahoma"><br>
My apologies, but I will be unable to make the call again this week. I
was hoping to have some suggestions regarding the infoset/data model for
discussion today, but it's not quite ready (I still have a little more
digging to do through the rest of the spec to make sure what I'm suggesting
can adequately capture all the representation cases in DFDL). I'll try
to get something out by the end of the day for review and discussion on
next week's call.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Tahoma"><br>
In general, it appears to me (and I'm admittedly not as versed in the various
XML standards as the other members of the group) that we can bring the
DFDL Infoset very closely in line with the XDM. Specifically, I've been
looking at the way XSLT 2.0 treats XDM as it's data model. It states clearly
that XDM is the model for XSLT with certain explicit caveats and additions.
This follows the XDM guidance of how it should be used by other standards
(specifically in XDM Section 7 and Appendix A). The task for DFDL therefore
consists of two parts: what parts of the XDM are in conflict with DFDL
and should be explicitly excluded, and what parts of DFDL have no corresponding
support in XDM and should be appended. Parts of XDM that have no relevance
to DFDL but are also not conflicting should probably be left in for conciseness
and compatibility.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Tahoma"><br>
My biggest concern is over the use of two different types of Element Information
Items in the DFDL specification as this seems so contrary to convention
in XDM. My recommendations include treating all element nodes similarly
to XDM as complex and those element nodes that actually only contain simple
content should have a single child of the XDM text node type or a new DFDL
value node type (not sure the best way to go here).</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Tahoma"><br>
In any case, I'll pass along a full recommendation soon.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Tahoma"><br>
Dave</font><font size=3 face="Times New Roman"> <br>
</font>
<div align=center>
<br>
<hr></div>
<br><font size=2 face="Tahoma"><b>From:</b> dfdl-wg-bounces@ogf.org [dfdl-wg-bounces@ogf.org]
On Behalf Of Alan Powell [alan_powell@uk.ibm.com]<b><br>
Sent:</b> Wednesday, May 06, 2009 6:01 AM<b><br>
To:</b> dfdl-wg@ogf.org<b><br>
Subject:</b> [DFDL-WG] Agenda for OGF WG call 6 May 2009</font><font size=3 face="Times New Roman"><br>
</font><font size=2 face="Arial"><b><br>
<br>
<br>
Agenda:</b></font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
1. Go through actions.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
2. LengthKind on Sequences and choices.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
<br>
LengthKind on sequences and choices and their parent element has proved
confusing to new users of DFDL. It is proposed that lengthKind is removed
from groups and only allow it to be set on parent element. See email from
SH</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
3. Discuss UnorderedInitated email from SH</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
<br>
4. Infoset codepage and encoding</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
<br>
The spec does not say what codepage and encoding is used for string fields.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
<br>
5. AOB</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
Next version (034)</font><font size=3 face="Times New Roman"> <br>
</font><font size=3 face="Arial"><b><br>
<br>
Current Actions:</b></font><font size=3 face="Times New Roman"> </font>
<p>
<table border=4 width=100%>
<tr valign=top>
<td width=12%>
<div align=center><font size=2 face="Arial"><b>No</b></font></div>
<td width=87%><font size=2 face="Arial"><b>Action </b></font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>012</b></font></div>
<td><font size=2 face="Arial">AP/SH: Update decimalCalendarScheme</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
10/9: Not allocated yet</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
17/9: No update</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
24/9: Add calendar binary formats to actions</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
22/10: No progress</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
16/1: proposal distributed and discussed. Will be redistributed</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
21/1: add locale, <br>
04/02: changed from locale to specific properties</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
18/2: Need more investigation of ICU strict/lax behaviour.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
08/04: Not discussed</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
22/04: AP to complete asap once the ICU strict/lax behaviour is understood.
<br>
29/04: No progress</font><font size=3 face="Times New Roman"> </font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>020</b></font></div>
<td><font size=2 face="Arial">SH: Resolve packedDecimalSignCodes<b> </b>behaviour
depends on NumberCheckPolicy <br>
22/10: No progress</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
10/12: added how to decide to overpunch and sign position</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
11/02: proposal largely agreed. SH to make minor changes</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
18/02: AP to document unsigned type behaviour</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
25/02: no progress</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
08/04: Not discussed</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
22/04: SH to complete last remaining issue, which is the behaviour when
logical type is signed/unsigned and the physical type is unsigned/signed.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
29/04: SH had identified a problem with definition values and types in
the infoset and will email proposal. DG to be asked to accelerate
action 032 to see if helps</font><font size=3 face="Times New Roman"> </font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>024</b></font></div>
<td><font size=2 face="Arial"><No owner> String XML type</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
08/04: Not discussed</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
22/04: Need to allocate owner. Work is to describe the semantics of using
dfdl:representation="xml" to model a well-formed XML fragment
in an overall non-XML document described by a DFDL schema.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
29/04: As no resource availbel to progress this action agreed to defer
from V1. Will close next week if no objections</font><font size=3 face="Times New Roman">
</font>
<tr valign=top>
<td>
<td>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>026</b></font></div>
<td><font size=2 face="Arial">SH: Envelopes and Payloads</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
08/04: Not discussed explicity, but recursive use of DFDL is tied up with
this</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
22/04: Two aspects. Firstly compositional - do sufficient mechanisms exist
to model an envelope with a payload that varies. Secondly markup syntax
- this might be defined in the envelope. <br>
The second of these is very much tied up with the variable markup action
028, so will be considered there. SH to verify the composition aspect.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
29/04: SH and AP working on proposal. related to Action 028</font><font size=3 face="Times New Roman">
</font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>027</b></font></div>
<td><font size=2 face="Arial">SH: Property precedence tables</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
08/04: Not discussed</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
22/04: Two things missing from the existing precedence trees. Firstly,
does not show alternates (eg, initiator v initiatorkind). Secondly, need
a tree per concrete DFDL object (eg, element). SH to update.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
29/04: No progress</font><font size=3 face="Times New Roman"> </font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>028</b></font></div>
<td><font size=2 face="Arial">SH: Variable markup <br>
08/04: Discussed briefly at end of call, IBM to see whether there any use
cases that require recursive use of DFDL.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
15/04: Use case was distributed and will be discussed on next call.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
22/04: The use case in question is EDI where the terminating markup for
the payload segments is defined in the ISA envelope segment. The markup
is modelled as an element of simple type where the allowable markup values
are defined as enums on the type. But we need to handle two cases - firstly
where the envelope is present, so the value used by the payload is taken
from the envelope. Secondly where only the payload is present. Here we
need a way of scanning for all the enum values, and adopting the one we
actually find, when parsing. And using a default when unparsing. SH to
explore use of a DFDL variable, where the variable has a default, but also
has a type that is the same as the markup element - that way we get to
use the enums without defining everything twice.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
29/04: SH and AP working on proposal.</font><font size=3 face="Times New Roman">
</font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>029</b></font></div>
<td><font size=2 face="Arial">MB: valueCalc (output length calculation)</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
08/04: Not discussed</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
22/04: Action allocated to MB, this is to complete the work started at
the Hursley WG F2F meeting.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
29/04: No progress</font><font size=3 face="Times New Roman"> </font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>032</b></font></div>
<td><font size=2 face="Arial">DG: Investigate compatibility between DFDL
infoset and XDM</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
08/04: No update</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
22/04: No update</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
29/04: No update</font><font size=3 face="Times New Roman"> </font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>033</b></font></div>
<td><font size=2 face="Arial">AP/TK: Assert/Discriminator semantics. AP
to document. TK to check uses of discriminator besides choice.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
08/04: In progress within IBM</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
22/04: Waiting for TK to return from leave to complete. <br>
29/04: TK has sent examples shown need for discriminators beyond choice.
Agreed. MB to respond to TK </font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>036</b></font></div>
<td><font size=2 face="Arial">SH: Provide use case for floating component
in a sequence</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
08/04: Raised</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
15/04: Use case sent and discussed. SH to do further investigation</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
22/04: IBM feedback from WTX team is that alternate suggested ways of modelling
the EDI floating NTE segment have significant usability issues. The DFDL
principle is that for a problem that can be expressed as two-layered, then
two DFDL models are needed. The EDI NTE segment does not fall into
this though, as its use is on a per sequence basis. Ongoing. <br>
29/04: Agreed that need to be in V1. SH to make a proposal</font><font size=3 face="Times New Roman">
</font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>037</b></font></div>
<td><font size=2 face="Arial">All: Approach for XML Schema 1.0 UPA checks.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
22/04: Several non-XML models, when expressed in their most obvious DFDL
Schema form, would fail XML Schema 1.0 Unique Particle Attribution checks
that police model ambiguity. And even re-jigging the model sometimes
fails to fix this. Note this is equally applicable to XMl Schema 1.1 and
1.0. While the DFDL parser/unparser can happily resolve the ambiguities,
the issue is one of definition. If an XSD editor that implements UPA checks
is used to create DFDL Schema, then errors will be flagged. DFDL may have
to adopt the position that: <br>
a)DFDL parser/unparser will not implement some/all UPA checks (exact checks
tbd)</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
b) XML Schema editors that implement UPA checks will not be suitable for
all DFDL models</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
c) If DFDL annotations are removed, the resulting pure XSD will not always
be valid (ie, the equivalent XML is ambiguous and can't be modelled by
XML Schema 1.0)</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
Ongoing in case another solution can be found.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
29/04: Will ask DG and S Gao for oppinion before closing</font><font size=3 face="Times New Roman">
</font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>038</b></font></div>
<td><font size=2 face="Arial">MB: Submit response to OMG RFI for non-XML
standardization</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
22/04: First step is for MB to mail the OGF Data Area chair to say that
we want to submit</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
29/04: MB has been in contact with OMG and will sunbit dfdl.</font><font size=3 face="Times New Roman">
</font>
<tr valign=top>
<td>
<div align=center><font size=2 face="Arial"><b>039</b></font></div>
<td><font size=2 face="Arial">SKK: Approach for creating Schema-For-DFDL
xsds. <br>
22/04: Resolve issue around multiple declarations needed for DFDL properties,
perhaps using MB's meta approach</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
29/04: Don't like qualified attributes in long form. SKK to check there
are no code gen implications, eg EMF.</font></table>
<br><font size=2 face="Arial"><br>
<br>
<br>
Alan Powell<br>
<br>
MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England<br>
Notes Id: Alan Powell/UK/IBM email: alan_powell@uk.ibm.com
<br>
Tel: +44 (0)1962 815073
Fax: +44 (0)1962 816898</font><font size=3 face="Times New Roman"><br>
</font>
<div align=center>
<br>
<hr></div>
<br><font size=2 face="Arial"><i><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font><font size=3 face="Times New Roman"> <br>
<br>
</font><font size=2 face="Arial"><br>
</font><font size=2 face="Courier New"><br>
<br>
--<br>
dfdl-wg mailing list<br>
dfdl-wg@ogf.org</font><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="http://www.ogf.org/mailman/listinfo/dfdl-wg" target=_blank><font size=2 color=blue face="Courier New"><u>http://www.ogf.org/mailman/listinfo/dfdl-wg</u></font></a><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
</font>
<div align=center>
<br>
<hr></div>
<br><font size=3 face="Times New Roman"><br>
</font><font size=2 face="Arial"><i><br>
Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
</font><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 face="Arial"><br>
</font><font size=2 face="Courier New"><br>
--<br>
dfdl-wg mailing list<br>
dfdl-wg@ogf.org<br>
http://www.ogf.org/mailman/listinfo/dfdl-wg</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
<br>
</font>
<div align=center>
<br>
<hr></div>
<br><font size=3 face="Times New Roman"> </font>
<p><font size=2 face="Arial"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font><font size=3 face="Times New Roman"> </font>
<p><font size=2 face="Arial"><br>
</font><font size=3 face="Times New Roman"><br>
<br>
</font>
<br><font size=2 face="sans-serif"><br>
</font>
<br><font size=2 face="sans-serif"><br>
</font>
<hr><font size=2 face="sans-serif"><br>
<i><br>
</i></font>
<p><font size=2 face="sans-serif"><i>Unless stated otherwise above:<br>
IBM United Kingdom Limited - Registered in England and Wales with number
741598. <br>
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU</i></font>
<p><font size=2 face="sans-serif"><br>
<br>
</font>
<br>
<br><font size=2 face="sans-serif"><br>
</font>