[DFDL-WG] Fw: DFDL: Action 027 - second rework of property precedence
Steve Hanson
smh at uk.ibm.com
Wed May 20 07:05:30 CDT 2009
Alan, Mike
Thanks for the feedback. Here is latest version that addresses all
comments except where noted below. The biggest changes are:
- Trimming & padding are now part of the 'extraction' & 'insertion'
phases, and not conversion.
- Complex element separated from simple element
- Simple type / local element / global element distinctions called out
- Repeat properties pulled forward into own phase
Notes:
1) Mike - I agree that dfdl:inputValueCalc and dfdl:outputValueCalc should
not be allowed in dfdl:format annotation (ie, scoping). Spec & xsds
should be updated.
2) Mike - you say that escape schemes are needed when looking for
initiators - we should discuss - I'm not sure this is a real requirement
in practice - I've never come across this.
3) Mike - the DFDL parser/unparser is driven by model position - not by
infoset position - you only get elements in the infoset.
4) Mike - I don't think that dfdl:initiatedContent is needed when
unparsing.
5) Alan - encoding and byteOrder do apply for sequence, choice and any,
because there could be markup involved.
6) Alan - lengthKind = 'pattern' - is this something that we should
support on complex elements - assumed so for now.
Regards
Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley, UK
Internet: smh at uk.ibm.com
Phone (+44)/(0) 1962-815848
----- Forwarded by Steve Hanson/UK/IBM on 13/05/2009 10:25 -----
My markup on this attached - mostly using comment balloons on the side.
Mike Beckerle | OGF DFDL WG Co-Chair | CTO | Oco, Inc.
Tel: 781-810-2125 | 100 Fifth Ave., 4th Floor, Waltham MA 02451 |
mbeckerle.dfdl at gmail.com
Alan Powell/UK/IBM
11/05/2009 16:57
To
Steve Hanson/UK/IBM at IBMGB
cc
dfdl-wg at ogf.org, dfdl-wg-bounces at ogf.org
Subject
Re: [DFDL-WG] DFDL: Action 027 - rework of property precedence - plus
issues arising
Steve
Comments
I don't think the tables answer the precedence of padding, escaping and
encoding that we had when discussing escape schemes. On parsing it should
be remove padding, remove escape characters, apply encoding. On unparsing
it is the reverse but the tables look the same.
I think the difficulty is that escape scheme is used for identification
and extraction but also during conversion.
I don't think the core properties (inputvaluecalc, etc) apply to sequence,
choice or any.
xxxPadKind is checked before xxxPadCharacter, xxpadxxx
Calendar-binary. binaryCalendarFormatRef is only used when binCalRep =
packed or bcd
Alan Powell
MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England
Notes Id: Alan Powell/UK/IBM email: alan_powell at uk.ibm.com
Tel: +44 (0)1962 815073 Fax: +44 (0)1962 816898
From:
Steve Hanson/UK/IBM at IBMGB
To:
dfdl-wg at ogf.org
Date:
08/05/2009 17:24
Subject:
[DFDL-WG] DFDL: Action 027 - rework of property precedence - plus issues
arising
I've created a separate property precedence for each schema object that
can carry non-scoping DFDL properties (attached for review).
The following issues were noted:
1) Missing property dfdl:textBooleanJustification - similar properties
exist for string, number and calendar types.
2) What is the rule when the same DFDL properties occur on a xs:simpleType
and a xs:element that uses that type? Does this work a) like
element/group references (ie, properties combined with element winning) or
b) like complex element and its sequence (ie, element and simpleType are
considered separate objects)? I don't think section 10 covers this case.
3) Should we allow the DFDL nil & default control properties on a simple
type? xs:nillable and xs:default are element only attributes in xsd. Spec
currently allows this.
4) Should we allow DFDL occurs properties on global elements? Whether
something repeats is a particle thing. Spec currently allows this. (IBM's
WTX and MRM don't allow this).
5) Missing work item to get BiDi properties into shape and incorporated
into spec. Should these be grouped, like escape scheme, calendar scheme,
etc? Do they apply to calendar and number types?
6) Should dfdl:integerBooleanXXXRep be renamed dfdl:binaryBooleanXXXRep ?
7) We might want to reconsider the name of the new flag dfdl:initiated -
it could be read that the xs:sequence itself is initiated rather than its
children.
8) Should dfdl:initiated also apply to xs:choice?
9) Draft 33 property precedence had dfdl:outputLengthCalc - but that is
not in the spec anywhere else?
Regards
Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley, UK
Internet: smh at uk.ibm.com
Phone (+44)/(0) 1962-815848
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[attachment "Property Precedence 034.doc" deleted by Alan Powell/UK/IBM]
--
dfdl-wg mailing list
dfdl-wg at ogf.org
http://www.ogf.org/mailman/listinfo/dfdl-wg
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20090520/7c7fd639/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Property Precedence 034-mikeb.doc
Type: application/octet-stream
Size: 179200 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dfdl-wg/attachments/20090520/7c7fd639/attachment-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Property Precedence 034.doc
Type: application/octet-stream
Size: 93696 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dfdl-wg/attachments/20090520/7c7fd639/attachment-0003.obj
More information about the dfdl-wg
mailing list