RE: comments on the xop draft

Erik,

We have added your three comments to our issues list[1] as issues 460,
461 and 462. We hope to address them today at our face-to-face meeting.

Gudge 

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Erik Wilde
> Sent: 02 March 2004 08:45
> To: [email protected]
> Subject: comments on the xop draft
> 
> 
> 
> 
> hello.
> 
> (* i posted this message on the [email protected] list a 
> while ago, but the [email protected] list seems to be more 
> active, so i give it another try on this list... *)
> 
> after reading through the xop draft, i have three comments to make:
> 
> - in section 4.1 (creating xop packages) shouldn't it be left 
> to an implementation to decide whether creating a part is 
> worth the effort? as i understand them, the current rules 
> specify that every base64Binary node must be optimized, which 
> can increase rather than decrease message size for small binary parts.
> 
> - when designing xml schemas, i usually avoid using xml 
> schema built-in types and create a layer of my own simple 
> types, which then are used in instances. i do this to be able 
> to restrict all simple types, for example with length facets. 
> wouldn't it be desirable to be able to optimize base64Binary 
> and restricted subtypes, rather than base64Binary only? as i 
> currently understand xop, my xml instances would not be 
> optimized at all, because they use types derived from 
> base64Binary. or would this be a requirement for my own type 
> augmentation software, to generate the appropriate type 
> information so that xop optimization works for base64Binary 
> and derived subtypes?
> 
> - just out of curiosity: what happens with whitespace in 
> base64Binary data? as i understand it, canonical base64Binary 
> data may not contain any whitespace. is this intentional, 
> because i think that many base64Binary does contain the 
> linefeed characters required by rfc 2045.
> whitespace certainly would disappear in xop, and as i 
> understand it, it cannot be reconstructed in the 
> reconstituted dm. not that i think this would be a 
> requirement, but i think this whole issue of whitespace in 
> base64Binary data should be mentioned in the document.
> 
> in replies to this message, please include my address 
> explicitly, if possible. thanks and kind regards,
> 
> erik wilde  -  tel:+41-1-6325132  -  fax:+41-1-6321035
>     mailto:[email protected]  -  http://dret.net/netdret
>     computer engineering and networks laboratory   (tik)
>     swiss federal institute of technology, zurich (ethz)
> 
>