comments on the xop draft

hello.

(* i posted this message on the xmlp-comments@w3.org list a while ago, 
but the xml-dist-app@w3.org 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:net.dret@dret.net  -  http://dret.net/netdret
    computer engineering and networks laboratory   (tik)
    swiss federal institute of technology, zurich (ethz)

Received on Tuesday, 2 March 2004 03:54:55 UTC