[dfdl-wg] Notes from Telcon 2006-04-06

[Westhead, Martin (Martin)]

Present


Martin Westhead

Tara Talbott

Mike Beckerle

Steven Hanson

Geoff Judd

 


Properties document


 

Some things that came out of the discussion (mainly from Mike who took
better notes than me)

 

-          clarification on Opaque vs. binary (details below)

 

-          Generally the naming scheme looks ok, even the very long
names like "syntaxFinalSeparatorCanBeMissing" are ok. 

 

-          Adding a conceptual UML taxonomy of the various
represetnation kinds would help to motivate the naming conventions used
for the properties. 

 

-          Want to break up big enums like repType and make them
extensible. So that a library can add values to it. 

 

-          Proposal: repType is a QName, not an enum, and a DFDL
processor adds libraries that register the valid strings for it as part
of their definitions. This allows refactoring the properties list into
libraries. 

 

-          Issues with library fragmentation: how small a subset of the
libraries can you have and still call it DFDL? Discussion: not too small
because you won't get interoperability. However, one can have data that
uses only a subset of DFDL features, and then you can have software that
only implements what you need. Your data and schemas will be DFDL
conformant in that anyone with a conforming DFDL implementation will be
able to read your data. However, you will not have software that can
process data you receive from others which uses more features. This is
an ok situation: conforming data and schemas, but subset implementation.


 

-          It would be good to be able to formally describe the subset
of DFDL constructs that a subset implementation provides. E.g., an XML
file which characterizes the subset formally.

 

-          Action for all to look at the paragraph in Steve's email
about default values.

 


Binary/Opaque issue: 


 

>From last week's notes: 

 

1.        Keep the group Binary. It covers situations where a binary
representation in the logical model is either what we really want or is
simply the best we can do. 

2.        Add the reptype 'text' to the group Binary. This is to cover
text representations of binary data. i.e. we want to interpret the bytes
on the disk as a text representation of binary data. [Question: what if
the representation is base64 but we would like the logical model to
represent it as xs:hexBinary? What if it is uuencoded?] 

3.        Add a new Group called Opaque. This would have the logical
type xs:any and the representations 'text' or 'binaryStream'. A text
representation means that this is an opaque string and it should be
included in the logical model as CDATA. A binary representation means
that it is an opaque Blob and it should be included in the logical model
using a binary representation. We can choose any binary representation
let us say hexBinary. 

 

Clarifications: an element of type hexBinary or base64Binary would
behave, at an API level as both a string (can deliver hex characters in
the case of hexBinary) and as a vector of bytes. 

An element of type Opaque would have no operations at an API level other
than copy(), and size(). 

 

Could also add as a representation kind for binary data: uuencode,
base100Binary, in addition to base64 and hex. 

 

 


Items for next week


 

- issue of defaults 

- arrays discussion

- outstanding property document discussion items

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20060405/aa5f13e4/attachment.htm