Re: EXP2ST: FLUTE FDT extension by element should be allowed

Hi,

I would also like to point out that the schema as written in RFC 3926 is 
not valid. It postfixes the two attributes elementFormDefault="qualified"
targetNamespace="http://www.example.com/flute"

of the schema definition with :xs which is not valid. I assume that this 
is simplest to assume that the correct schema is without these ":xs".

Cheers

[email protected] wrote:
> Hi All
> 
> As promised, here's another point to consider in the standards track progress of FLUTE...
> 
> The FDT (XML) schema is intentionally open to extension by both element and attributes. On oversight of the original creation was that "<xs:anyAttribute processContents="skip"/>" allows extension by attribute but not by element.
> 
> Naturally this has not interfered with any interoperability based on the specification. However, when using FLUTE as the basis of an enhanced application protocol this issue has been discovered.
> 
> Both the MBMS (3GPP/cellular multicast) (http://www.3gpp.org/ftp/Specs/html-info/26346.htm §7.2.10) and RMT/individual Object Aggregation I-D (http://www.ietf.org/internet-drafts/draft-neumann-rmt-flute-file-aggregation-00.txt, §4.3) have already encountered the need to extend by element, and thus extend the FDT in this way. [For those interested: IPDC/DVB-H and OMA work (also using FLUTE) has taken this into account in contributions].
> 
> Hence, I propose that we repair the FDT schema. The fix is to introduce "xs:any processContents="skip"" into both "FDT-Instance" and "File" elements, and thus any extension processes (elements) will be skipped by an non-enhanced FLUTE client whilst leaving the rest of the FDT Instance valid and usable by the client according to the schema. i.e. add this twice:
> 
>    <xs:any processContents="skip" minOccurs="0" maxOccurs="unbounded"/>
> 
> This is fully compatible server side. However, an experimental client encountering an element-extended FDT ought to reject it as not adhering to the experimental schema. Basically this would be "graceful failure". Then the difference between an experimental and standards track FLUTE client would be that the latter could use the remainder of an FDT Instance's data, whereas the former should reject all data of an FDT Instance including an element-extension. Given that FDT extensions are for specific enhancements and applications it would be unlikely that this will cause any problems, even if there were already a large number of deployed experimental FLUTE clients. (Please shout up if you have such a large deployment - it's good to know in any case :)
> 
> So I am happy that the change is not going to break anything in practice - even to the experimental FLUTE. And the change will also simplify future extension and inter-working with the broadcast/datacast/wireless standards work.
> 
> Comments, experiences, issues are welcome.
> 
> Cheers, Rod.
> 
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmt
> 


-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email protected]