[DFDL-WG] BLOB - binary large object proposal - updated

[Steve Hanson]

Mike

Am I allowed to put DFDL properties on the new simple type, or is the new 
type considered to be a built-in type?  I think the latter is clearer and 
simpler to implement.  Support for 'clob' would then just add a new simple 
type restriction 'dfdlx:clob'.

Assuming that the feature makes it into a future DFDL 2.0, the schema 
containing the 'blob' simple type would then be in the standard DFDL 
namespace. That's the first example of such a schema, as this is the first 
time we are extending base XML Schema as opposed to defining annotations. 
If the new type is considered a built-in type, then this schema should be 
part of the DFDL 2.0 standard and read-only.

Any thoughts on allowing the specification of the filename via DFDL 
property rather than API call?

Presumably I could create a local restriction of 'dfdlx:blob'? One 
motivation for so doing would be to validate the length or content of my 
binary data. There's a problem with that though - validation works against 
the infoset, so the allowable facets are those applicable to xs:anyUri and 
would be applied to the file name, not the binary data. It also means that 
dfdl:lengthKind 'implicit' can't be used.  I don't see a way round this.

Regards
 
Steve Hanson
IBM Hybrid Integration, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday 



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     DFDL-WG <dfdl-wg at ogf.org>
Date:   12/07/2019 18:14
Subject:        [DFDL-WG] BLOB - binary large object proposal - updated
Sent by:        "dfdl-wg" <dfdl-wg-bounces at ogf.org>



This concept, ,which has been discussed before, is in high demand in the 
Daffodil user community to enable DFDL to be used to parse image file 
formats.
The use case is to provide uniform image-metadata access without getting 
bogged down in the large byte-array that makes up most of the file and 
would be very large (and pointless) if rendered into XML or JSON. 

So our proposal, (which will get turned into an official Experimental 
feature document), has been simplified and revised and is described here: 

https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Binary+Large+Objects

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | 
www.tresys.com
Please note: Contributions to the DFDL Workgroup's email discussions are 
subject to the OGF Intellectual Property Policy
--
  dfdl-wg mailing list
  dfdl-wg at ogf.org
  
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ogf.org_mailman_listinfo_dfdl-2Dwg&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=AJa9ThEymJXYnOqu84mJuw&m=SF--m_AQsLDJXIRlIiIgKt2VyG_gUX1UdSKnUNxzkEA&s=iLv6L9sbOkKdNDFWCFQrCpgsghOFmYWfFlM6uzY6MDE&e= 


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/20190808/8ed7ba10/attachment-0001.html>