See also: IRC log
<shadi> http://www.w3.org/TR/2006/WD-HTTP-in-RDF-20061220/
<shadi> http://www.w3.org/WAI/ER/HTTP/issues
SAZ: We have got a fair few comments from
various places. Should we do another WD before we publish it as a Note?
... Issues list...
SAZ hands over to JK
JK: Already talked about this in telecon.
... think the htp:response approach would be good. There is an issue in EARL
because we have a higher-level connection, but to use this outside EARL we
should move that here.
CMN: Agree
RESOLUTION: Make http:response part of this vocabulary, so close issue 001
RESOLUTION: Add http:version
RESOLUTION: Add http:responseCode (and there should be a version, too)
SAZ: Danny Ayers proposes to make a Class of response codes.
JK: They are defined in HTTP 1.1 (RFC 2616), but there may be others possible
SAZ: Does it make sense to have predefined
values?
... you can always subclass them and create your own.
<Zakim> chaals, you wanted to say yes
CMN: What Shadi said. So long as we don't make it an exclusive list it makes a lot more sense to me that we provide a class that covers known responses.
RESOLUTION: Have a class for response codes listing the defined ones from RFC 2616, but not in a closed list...
<scribe> ACTION: Johannes edit the spec to add an extensible Class enumerating known HTTP codes. [recorded in http://www.w3.org/2007/02/22-er-minutes.html#action01]
CI: Sometimes properties have a hypen, sometimes it is camelCase. Are we following a particular style or does this happen by random?
JK: The rule I had was that header properties
use the name of the header, e.g. Content-type
... for other properties which were two words, e.g. Respnse Code, I used
camelCase
CI: Makes it a bit unpredictable what the names will be.
SAZ: Should we write this down in a "conventions in this document" section?
CMN: I think we should
JK: BTW I have seen Status Code for Response Code. Do we want to change the name?
SAZ: They use both in the RFC...
CMN: So we should leave it alone....
<scribe> ACTION: Johannes add a section on "conventions used in this document" which would include description of how names are formed [recorded in http://www.w3.org/2007/02/22-er-minutes.html#action02]
JK: I don't think we should do this
CMN: Nor do I
JK: Not sure if we could run into a problem with someone defining a thing that we already use.
SAZ: We can deal with that if it happens...
Also don't think we should add -header
... can make a new namespace to deal with a conflicting name. But I doubt
HTTP will change that quickly.
RESOLUTION: We reject the proposal to add -header and close issue 005
SAZ: Related to Issues 13 and 16. There was quite a heavy pushback related to this
JK: Because most people think of storing text
content and not binary.
... currently we use a generic approach so we can store everything. But not
handy for people processig text-based content, or XML.
CMN: You could use parseTypes for the common
text cases, and use <h:body r:resource="data:....."/> where you need to
encode binary data, things with wierd angle brackets, or just to annoy people
trying to use XSLT...
... has the probably happy coincidence that two identical files which are in
two places on the web can be the same rdf resource and you suddenly know
that.
... e.g.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGQAAABkAgMAAAANjH3HAAAADFBMVEX%2F%2F%2F8AAI8A%2FwAAAABMtl%2FaAAAAIXRFWHRTb2Z0d2FyZQBHcmFwaGljQ29udmVydGVyIChJbnRlbCl3h%2FoZAAAAMElEQVR4nGIIxQUYRmVGZYaGDAMyEB2VGZUZlRmVGQkyWMCozKgM9WUAAAAA%2F%2F8DACpBXnJ8ZaKcAAAAAElFTkSuQmCC
... is a little blue square PNG.
JK: This would be a representation of the body,
not the body itself.
... e.g. if your body text came through encoded as Big5, what do you use for
an encoding?
... or where the server did not provide an encoding?
CMN: Why not say that it is UTF-8 unless otherwise declared?
JK: Because you get invalid byte sequences if
you try that.
... think this is a problem.
CMN: So if you have wierd junk, you base-64 encode it to a data: uri, if it is clean XML you drop it in with a parseType.
SAZ: There is a large use case for HTML that is
tag soup. We should not assume well-formed XML
... so should have a method to enforce plain text.
JK: Should we use a different property for text stuff? Additional to always having a base64-encoded body?
CMN: I don't see why. Lots of overhead for little benefit.
JK: It is a different thing. The original stuff is the byte sequence.
SAZ: We could have two types - one for literals/XML, one for base64
CMN: For XML, an XML version is as accurate a
representation as a base64 encoding (and more useful)
... you could make subproperties of body, to have body-b64encoded
SAZ: That would allow you to have both there if you wanted.
JK: Would do it the other way around - body still b64 encoded.
[Discussion about how to deal with character encoding issues...]
CMN: Proposal: You can use data:uri to base64
encode the original byte stream of the body any time you like. You are
encouraged, where the body is a literal or XML literal that can be safely
represented in the RDF, to include it with a parseType, and if the original
character-encoding was different, you must first transcode it to the encoding
of the RDF document.
... Complicated proposal, something like the following process:
... Is it a non-text type? [encode as data: URI] else
... What is its character encoding? [None / Same as the RDF we are
generating: if it is safe to include as a Literal, do so, otherwise data:URI
]
... else Convert the characters to the encoding of the RDF we are generating,
according to the character encoding it claimed to be then
... if it is safe to include as a literal, do so, otherwise convert the
original byte stream to data: URI
(i.e. character data is always normalised to that of the RDF document, according to the encoding supplied in the HTTP response. Data: URIs are always generated from the original byte stream with no transcoding.
scribe: where feasible, include as XML, failing which as literal, failing which as data: URI. Being lazy is one reason to claim it is not feasible to include a literal - just not a good one)
RESOLUTION: porposal by chaals accepted (see prose and additional pictures); no cardinality restriction on body property
issue 012: 'RFC822 in XML' draft by Graham Klyne
PROPOSAL: contact Graham and ask him to review HTTP in RDF
RESOLUTION: contact Graham and ask him to review HTTP in RDF
ACTION SAZ to contact Graham Klyne to review HTTP in RDF
<scribe> ACTION: SAZ to contact Graham Klyne to review HTTP in RDF [recorded in http://www.w3.org/2007/02/22-er-minutes.html#action03]
issue 017 sounds interesting, chaals could ask Kjetil to write some more about this use case, we'll include this
CMN: issue 011, write more elaborate, if there is time
CI: new use case: reporting usablility testing,
user paths through a web site
... use cases are clear to us, but not necessarily to 'outsiders'
RESOLUTION: use cases should be elaborated to be more useful
CMN: use case 3: use HTTP vocabulary for tracking in web applications
RESOLUTION: keep the three
existing use cases
... add editor's note for reviewers to let us know about new use cases
<scribe> ACTION: chaals to ask Kjetil to write more about his use case [recorded in http://www.w3.org/2007/02/22-er-minutes.html#action04]
<scribe> ACTION: JK to check for possible changes in RFC 2822 compared to RFC 822 [recorded in http://www.w3.org/2007/02/22-er-minutes.html#action05]
SAZ: issue 014: if there are no substantial
changes related to our work, update the reference
... issue 015: in the beginning we had a separate document for 822
RESOLUTION: separate document 'RFC 2822 in RDF' is out of scope of our work
<scribe> ACTION: SAZ to explain resolution about issue 015 to Karl [recorded in http://www.w3.org/2007/02/22-er-minutes.html#action06]
CMN: drop rfc 822 and put the stuff in http namespace
<chaals> [Proposal: Change the example so it is in the current namespace, using camelCase names we make up]
SAZ: MessageHeader class with fieldName and
fieldValue properties in http namespace
... so drop any reference to RFC (2)822
RESOLUTION: in section 4 drop references to RFC 822, and take up terminology from RFC 2616 (MessageHeader class with fieldName and fieldValue properties in http namespace)
issue 006
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007Jan/0005.html
CMN: we won't create a more sophisticated URI class, if someone wants to create it, fine
JK: we need server/port and requestURI
continue discussion about URI
RESOLUTION: Johannes proposal was accepted (see picture)
<chaals> [ page 50 of rfc 2616 [[[If client sees that the connection is closed prematurely,
<chaals> repeat from step 1 until the request is accepted, an error
<chaals> response is received, or the user becomes impatient and
<chaals> terminates the retry process. ]]]
<chaals> ]
RESOLUTION: subtype requestURI
into the four subtypes defined by rfc 2616 5.1.2 (*, absoluteURI, abs_path,
authority)
... keep the Connection staff in the same namespace as the http staff
CMN: if somebody comes with a really intelligent Connection class we could adopt it
RESOLUTION: the URI authority
property will be connectionAuthority
... ask for review on the hole Connection staff
... the current URI property will be dropped in favor of the new Connection
staff
<scribe> ACTION: everybody think about the overall impact of the new Connection staff on EARL [recorded in http://www.w3.org/2007/02/22-er-minutes.html#action07]
Draft -> http://lists.w3.org/Archives/Public/public-wai-ert/2007Feb/att-0038/note.html
CI: We should add a scenario for Web Content Labelling - point out which bit of a document is kid-friendly or written in spanish or usable on a mobile phone...
SAZ: Should say that PointerCollection is a subClass of pointer in the text as it does in the schema
CMN: The examples are lovely, but they should not be in 1pt white text
JK: propose to make line lineNumber for clarity
SAZ: Missing whether we start with zero or
one.
... think it should be zero, but it definitely should be specified.
CMN: I think that we should start everything from 1 or everything from zero, rather than some of one and some of the other.
CI: Why is it inconsistent?
[discussion about the legendary discussions lost in the mists of time]
<scribe> ACTION: Shadi to get a response from Jim on these comments... [recorded in http://www.w3.org/2007/02/22-er-minutes.html#action08]
RESOLUTION: These are editorial comments, and we expect the editor to answer them one way or the other
CI: Do we want a pointer that has start and end? Or a Range class that has a pointer to the beginning and another one to the end?
CMN: I think we should do this.
JK: There are pointers that identify specific
points in the resource. Xpath can point to a range already...
... or at least a node.
CMN: You should be able to use different types of pointer for the start/end of the range.
JK: You need to know if you have a start or end pointer that covers a node whether the node is included in the range.
CMN: Think in this case that the content should be included.
JK: there is no way to specify range with a LineCharOffset pointer?
JK/CI: How do you define the scope of a Pointer?
scribe: important because you want to be able to point to a piece that moves, and point within that.
CMN: EARL defines the pointer property to set
an initial scope.
... within that, could you use a range to describe the scope?
CI: This specis not cmplete without EARL. So I think that it should include a way of expressing the scope within which the pointer operates
CMN: Agree. This would enable you to point into a previously described range, where things move around but you can deal with a chunk of it
SAZ: If there is a nice resource, what if the pointers point to another document
CI: In this case the pointer should describe the scope as the same thing that we have already identified as the subject.
JK: There should be some reference property so the pointer can declare the sope within which you use it.
[discussion about what a reference should have as a range]
SAZ: What should it be?
CMN: It should be a resource. It gets to the
tricky issue of saying what exactly the resulting pointer/range is, so you
can describe how a pointer applies to it.
... For the case <reference r:resource="foo"/> it means you apply the
pointer to the thing identified by foo (which may be the body of something
you described using the http vocab, or may be a range described by a
pointerCollection, or may be your maiden aunt - and then you figure out which
pointers still apply).
... (this is the nasty bit about identifiers being http URIs not
*necessarily* meaning that there is something at the end of the URI, that led
to us describing the http vocab in the first place)
SAZ: Should we describe the use cases and how they would be handled?
[the problem gets tricky when you refer to a body that uses a data: URI to encode itself]
CMN: You are dealing with something where the
only useful pointer we have is a ByteSnippet. Since you happen to have the
data in base64, the processing requires magic but it ain't hard.
... and you can make a nice RDF id to it by saying it is owl:sameAs
somethingShort
RESOLUTION: The range of the reference should be an RDF resource - and then we need to add hints about how to use it wisely
<shadi> SUMMARY OF COMMENTS: 1. Web content labeling use case, 2. PointerCollection is sublclass of Pointer, 3. clarify that line/char properties refer to *numbers* (spell that out in the text of the document), 4. define the start values for counting (see old EARL Schema and minutes for previous decisions), 5. consider a start/end pointer (and determine the repitition impact on the length in the line/char/len pointer), 6. consider ranges also within snippets, 7. add a "refer
CMN: Leave it out!!!!
SAZ: Oh, and the domain/range should be adusted
to make this stand on reference not rely on EARL spec.
... What do multiple xpointeres mean?
CMN: You can make different ones (constructed differently) to point to the same place, for robustness over change to the doc
SAZ: There is a selectorpointer that is only
half described...
... Instance property belongs in earl, too
... Limit cardinality for linecharthing?
CI: Let's stabilise the schema before we think
too hard about cardinality
... Would like to have a class that can point to things in several different
documents.
... somethign different between a group of pointers that are just a
collection, and a group of pointers that you are using together for some
purpose.
SAZ: Can we have a class for this?
CMN: Would like to sleep on it (but think it makes sense at the moment)
SAZ: The HTML pointer is a little under-specified here...
Adjourned!
continue at 10am local time.
(that's 7am Jibberjimtime, I think)