Martin
Westhead
Tara
Talbott
Mike
Beckerle
Steven
Hanson
Geoff
Judd
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.
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.
- issue of defaults
- arrays discussion
- outstanding property document discussion items