[DFDL-WG] Are non-native attributes allowed on DFDL annotation elements?

[Steve Hanson]

IBM DFDL has handled its DFDL extensions using short-form attributes on 
the xsd objects and not the annotations.

Regards

Steve Hanson
Architect, IBM Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     dfdl-wg at ogf.org, 
Date:   27/03/2013 02:54
Subject:        [DFDL-WG] Are non-native attributes allowed on DFDL 
annotation      elements?
Sent by:        dfdl-wg-bounces at ogf.org




In XML Schema you are allowed to throw in attributes even just as 
documentation i.e.,

<xs:element xmlns:rtfm="read:the:..manual." name="myElement" rtfm:yo="this 
element name is general lameness" .../>

I.e, in the definition of xs:element there is this wildcard with standard 
lax validation for any non-native attributes. 

So, the question is do we want to also allow that on dfdl annotation 
elements, i.e, 

<dfdl:format byteOrder="bigEndian" rtfm:yo="it's LE Loser!" />

Given that you cannot nest <!-- style comments --> inside element syntax, 
these non-native attributes are the only convenient way to add commentary 
to the attributes of a XML document.

Another perhaps more compelling reason to tolerate this is that I am sure 
in the next year all the DFDL implementation efforts are going to add some 
new experimental properties, and we will want to hang them on the same 
dfdl annotation elements. Schema inter-operation requires us each to 
tolerate the other's such experimental properties to the extent that they 
are not essential to the schema being usable at all.

So if I have:

<dfdl:element dafext:recursive="typesOnly" 
xmlns:dafext="some.daffodil.urn.for.extensions"  ref="someOtherFormat" /> 

then we will want IBM DFDL and DFDL implementations generally, to perhaps 
warn that it was there and unrecognized, but not to just SDE on 
non-validation.

Today, the XML Schemas for DFDL Annotations do not allow non-native 
attributes inside DFDL annotation elements, but the spec is silent on the 
subject. 

I was considering adding a couple of experimental properties (not right 
away, but maybe by year end), and I only realized today that they would 
break compatibility without a change here. 

Comments?

-- 
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | 
www.tresys.com
--
  dfdl-wg mailing list
  dfdl-wg at ogf.org
  https://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130327/55ba7095/attachment.html>