<DanC_csail> ^ a little story about how I
should have reported a browser bug but didn't because it's a pain to manage
yet another password

<Norm> ack

<Zakim> Norm, you wanted to ask about
schema validation

Norm: What if schema processing of eg default
atrributes is necessary?

<Zakim> ht_hotel, you wanted to talk about
several layers of semantics

DanC: So long as the trail by looking up the ns
of the doc element leads you to that one way or another, otherwise your
document is not grounded on the web.

HT: We start with the infoset ... can we using
specs define how to get from that to the application data model?

<Zakim> noah, you wanted to say there's no
one schema for a given media type

HT: The question is can we say whether or not
to do things like XInclude and decryption etc.

Noah: There are dangers when your content
depends on an external document. There is no well defined way of finding a
schema.

DanC: The AWWW says the namespace is a good way
to look.

Noah: Maybe we should say don't use
defaults?

Henry: Defaults are not the only problem ...
you can get the same problem with types anyway.

<ht_stata> timbl: Please clarify what the
failure scenario is

DanC: We can just use namespce pointers.

Noah: Some people believe that there are
multiple schemas for the same namespace. I think people change schemas after
documents have been written so you should be careful and we should warn
against using them.

Tim: [shock, horror]

Noah: People change schemas when those schemas
do not have effects of changing the document. Those people don't use
defaults. They may point from RDDL document to many schemas, all by different
people.

<ht_stata> I find that implausible, because
the RDDL document _is_ owned by the namespace owner, by construction.

<ht_stata> Noah: People who write a new
schema for a namespace they don't own are doing so to gear up for a form of
processing they want to do, _not_ changing the 'fundamental meaning' of the
original document.

Norm: How does what you said about Xinclude
work....

Tim: XHTML has to say it accepts XML
functions

Norm talks about document photo'd

<ht_stata> NW: fizbar example

<ht_stata> TBL: That's functional iff it
can be understood as replacing itself with new info, dependent only on its
own contents.

<ht_stata> NM: What about DSig?

<ht_stata> TBL: Some uses are functional,
some [those which point over to the signed part] are not.

<ht_stata> NM: Suppose we go there, will
you have to opt in on an instance-by-instance basis, or will pre-existing
documents get captured?

<ht_stata> ... It would be a pain to have
to mark everything going forward.

<ht_stata> TBL: Not a big problem.

<ht_stata> NM: We encourage apps to use the
definitive interpretation, specs to say they depend on it.

<ht_stata> DC: You shouldn't have to opt
in.

<DanC_csail> I misspoke; yes, for stuff
like xml:base, you should have to opt in. sigh.

HT: That is not obvious, needs explanation as
it is not clear to the reader.

DanC: For example, we could imagine an
imaginary news language, maybe.

HT: Or we could talk about 408 no acceptable
form response.

DanC: It isn't usual to have the type attribute
affect the accept header.
.... It is normal to send accept: for everything one understands, no?

RF: Yes, but optionally, one can trim the
things things in the metadata.
.... It would be better if Stuart did not misconfigure the server, and
changed the style sheet language for some reason.

That is, the title of the section should be changed.

<Roy> 6.3 example would be better if it
doesn't say misconfiguration, and instead Stuart replaces one stylesheet
language with another.

<Zakim> noah, you wanted to discuss
processing vs. interpretation

<Roy> 6.3 should also describe 4xx case of
content negotiation with accept.

Noah: I had sent a response to Roy on an
intermediate version of his draft. Overall, this is much improved. I like
that it now explains that different agents can process the same document
differently. However, in 3.1, it still talks about "processing". I would
prefer "the mediatype gives the preferred interpretation" as opposed to "the
media type tells you a particular way you must process". We shouldn't tell
people what to do.... we should say "this is music" not "play this".

Tim: Not preferred ... intended or
definitive.

<Roy> NM: "The media type indicates the
intended interpretation for a representation".

Tim: I like the word "interpretation" .

RF: I ran out of new an interesting examples --
send your suggestions!

<noah> So, I'm suggesting that in many of
the places where it refers to "intended processing", I would prefer "intended
interpretation".

RF: I added some more teeth to the
suggestions, with SHOULD and MUST... we should look at those probably.

<noah> I'm fine with Tim's suggestion that
those should in fact be "Definititive Interpretation".

The previous finding said the findings MUST not work
against eth web architecture.

DanC: I am OK with that.

Tim: Me too,

Ed: How do we tell what the most authoritative
when there is a clash?

DanC: The readers should pick the most
authoritative. If there is anconsistency they won't notice.

Ed: In the summary of the key points, it says
the processing should be stopped.

RF: No.. it says should be detected and
reported... Doesn't say what happens to the processing.

DanC: It is not an error to ignore the less
authoratitive.

Ed: That makes sense.

<DanC_csail> ... esp point 3

<DanC_csail> RF: I'll think about that and
see if I can find better words.

<DanC_csail> RF: let's look at the
admonitions in 4.2....

RF: It should say in the third bullet "when the
media type is unknown".

<DanC_csail> 1st bullet in 4.2

DanC: Suggest you put the two SHOULD NOTs at
the end. You mean really don't send anything if the media type is unknown?
Not text/plain or application/octet-stream?

RF: Yes.

HT: Yes, importantly, as if it says something
then that stops the client from being able to sniff, etc.

<Zakim> ht_stata, you wanted to ask about
text/plain as a form of protection

Noah: Going back to Henry's comment about
XInclude. I don't think XInclude is special. Rather, it's an example of
noticing that types often have supertypes. XML is also Unicode text. So, I
don't think XInclude contradicts the finding. E.g. an XML document is a
subtype of Unicode, rdf/xml is a subtype of xml. I could treat it as any
level -- I'm not overridin it.

[NEW]ACTION: NM to announce draft finding
of principle of least power to www-tag in ~ 2 weeks [NEW]ACTION: Norm to Format the section as
a finding. [NEW]ACTION: Norm, with help from Henry,
to produce a draft finding on XML functions in January. [NEW]ACTION: RF to Produce a new version
of the finding http://www.w3.org/2001/tag/doc/mime-respect.html
by the end of the year