[BXXPwg] Items of WG consensus

Steven E. Harris seh@speakeasy.org
21 Aug 2000 08:35:16 -0700


"Marshall Rose" <mrose+mtr.netnews@dbc.mtview.ca.us> writes:

[...]

> if we get rid of nesting for XML-based channels, then we can use the same
> solution for all channels. in that case, probably the easiest solution is to
> add an 'encoding' attribute to the profile element, e.g.,

[...]

> the key thing here is that everything is PCDATA, but maybe base64 encoded if
> if contains "funny" characters.

This looks great from here. It would be useful to say that each
profile must define what possible values for the encoding attribute it
may use. That way, you wouldn't wind up in the situation where you
think that you can adequately speak to a profile, but then your peer
chooses some encoding that you haven't implemented yet. Base64, for
example, is pretty easy to implement, but there may be other ones we
don't know about yet that you wouldn't want coming down the wire
before you've at least heard of it.

> i would still prefer to use XML's natural nesting abilities for XML-based
> channels, though i can see the appeal of having one way of handling both.

If each profile had the *same structure* for its piggyback content,
I'd support the XML-based way. That is, if the structure was something
like

<start number="1">
  <profile uri="http://wearetheneweconomy.com/profiles/mygoodside">
    <val n="foo">bar</val>
    <val n="bax">burp</val>
    <!-- ... -->
  </profile>
</start>

then you could have a clear "model" for what piggyback content is: a
list of (key, value) tuples. To make the model's simplicity even
clearer, then "val" elements could take the more restricted form

    <val n="foo" v="bar"/>

showing that the element content is empty, with the data captured as
attribute values.

Once you settle on something like this, a BXXP library can hand over
the piggyback data to each profile in a consistent, known way. It's
more complicated than the #PCDATA idea, and arguably less flexible, so
I still vote for the #PCDATA idea.

-- 
Steven E. Harris        :: sharris   @primus.com
Primus                  :: http://www.primus.com