comments on the xop draft


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  -
   computer engineering and networks laboratory   (tik)
   swiss federal institute of technology, zurich (ethz)

Received on Tuesday, 10 February 2004 10:22:23 UTC