From: "Michael Day" <mikeday@...>
>
> > In its place, I have tentatively added a "version" attribute...
>
> Is it optional? :)
>
> > Hmm... Yes, it would probably be a good idea. I'll have to work on
that
> > one ("infoset... *blech*").
>
> Well, the other alternative would be to *not* require a whole document
> comparison, if all you really care about are the two identity and inbox
> URIs. That way the software could just store the URIs rather than worrying
> about storing the entire documents, and just compare the URIs with those
> in the document that comes back. Avoids the quagmire of normalisation,
> canonicalisation and augmented frankinfoset comparison :)

Yeah, that's all I really want (at least for the inboxAgreement).

> However on the subject of normalisation... comparing two URIs is not
> exactly straightforward either.

True. Maybe the TAG will finally come up with something to work with.
However, since there are only two entities involved in the creation of the
document, I may be able to say that the values of the URI attributes are not
alterable once added to inboxAgreement, which means the comparisons can be
done on at the character level. If an entity decides to alter such a value
(even if the altered URI resolves to the same resource) and the other entity
rejects the document as a result, so be it.

> > Yes, almost all of the elements allow optional content. However, they
do
> > not allow mixed content. They must be elements only. So instead, you
could
> > have:
> >
> > <to uri="mailto:mikeday@...">
> > <ns:commonName>Michael Day</ns:commonName>
> > </to>
>
> Okay, so in RDF terms the children of the from/to/cc elements are
> predicates that relate to the uri given in the attribute...

Yes, that would be an accurate statement. However, there are no
restrictions on what can be within those elements. Mixed content, PCDATA
only, etc.

> > On the other hand, if you are just suggesting the ability to put a
plaintext
> > name in for <from>, <to>, and <cc>, I'd be more inclined to add a "name"
(or
> > some such) attribute:
> >
> > <to uri="mailto:mikeday@..." name="Michael Day" />
>
> Okay, now I'm torn between your proposal for infinitely extensible
> metadata, RDF-style, or a more XMLish approach of allowing mixed content
> and arbitrary markup inside the element, which could of course still have
> metadata in attributes.

Well, i am still of the mind to go the pseudo-RDF route, where elements can
contain only elements relating to the URI, but that those elements can
contain anything they want. For instance, if someone wanted to add xhtml,
they would need to use something like <xhtml:body>.

As for the "name" attribute above, I am just suggesting to add that as part
of the RNA spec. On the other hand, I could add an optional child element
<name> which could contain mixed content. The rules for application
processing would be the same as the <subject> element (see below).

> For example, this recently came up on the CSS list, when Andrew McFarland
> pointed out that in his name the "c" in "Mc" should be superscript:
>
> <to uri="..."> Andrew M^cFarland </to>

So how has he survived using e-mail all these years?

> And the i18n guys are putting strong pressure on the XHTML working groups
> to use element content rather than attributes for human readable text.
>
> I suppose it needs some more thought. Perhaps there are some cooler things
> that can be done with the RDF-style metadata, I don't know.

Yes, I agree. More pondering would be good.

> > I'm not sure I'll budge on this one. Allowing <subject> to contain
markup
> > feels like opening a pandora's box to me. Further, it can greatly
> > complicate user interfaces to be able to support <subject>. In all of
the
> > other elements, additional content can be optionally ignored (see
> > extension), but I think it would be hard to effectively ignore markup
inside
> > <subject> and still keep subject useful...
>
> Markup can be ignored simply by taking the text and ignoring the tags, so
> it needn't complicate any user interface that doesn't want to deal with
> it. For example:
>
> <subject> Hey, today is <strong>your birthday!</strong> </subject>
>
> which may be rendered with appropriate bold fonts in a graphical user
> interface, could easily be rendered "Hey, today is your birthday!" in Lynx
> or Pine or a mobile phone or any other text based interface.

So what you suggest is something like:

The <subject> element may contain mixed content. However, if an application
processing <subject> does not know how to handle contained elements, those
elements will be ignored while the PCDATA within them will still be
processed. The choice of which vocabulary is used within <subject> should
take this behavior into account for greater compatibility.

---
Seairth Jacobs
seairth@...