Input: [Commentor] LC-2814 Ashok Malhotra (archived comment) [Comment] The spec also says nothing about authentication. Should we specify some minimum level of authentication, for example: LDP servers that require authentication SHOULD consider supporting basic authentication as specified in *[**RFC2617]*** over HTTPS for the highest level of interoperability with generic clients. They MAY also support other authentication methods. [Commentor reply] yes [Working Group decision]

Output: Same as LC-2813.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2815 Ashok Malhotra (archived comment) [Comment] We discussed that LDPCs are a subclass of LDPRs and so containers can be members of other containers. Do we say that somewhere? I could not find such a statment. Perhaps we need to add it. Also, of a container contains other containers, how would ordering work? [Commentor reply] tocheck [Working Group decision]

Output: Added some informative content to 5.1.2 Ordering section.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2816 Ashok Malhotra (archived comment) [Comment] Some comments on section 5.1.4 Ordering 1. Why is this section non-normative, given that it defines ldp:containerSortCriteria and ldp:containerSortPredicate [Commentor reply] yes [Working Group decision]

Output: Erroneous comment. See http://lists.w3.org/Archives/Public/public-ldp-comments/2013Aug/0005.html

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2838 Tim Berners-Lee (archived comment) [Comment] How does a client find the non-member-property version of a resource R? [Commentor reply] tocheck [Working Group decision]

Output: This is defined by the response header of the form: Link: rel="http://www.w3.org/ns/ldp#nonMemberResource" This is detailed in section 5.9.1 http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpc-5_9_1

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2839 Tim Berners-Lee (archived comment) [Comment] 4.10.1 "The triples in the representation of the each page are typically a subset of the triples in the resource - same subject, predicate and object." Same triples then? eh? I prefer the word "inspect" for the way "introspect" is used in the document. "Introspection" is normally looking into oneself, not into something else. [Commentor reply] tocheck [Working Group decision]

Output: Changed the offending text to clarify intent and use inspect rather than introspect per Tim's recommendation.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2840 Tim Berners-Lee (archived comment) [Comment] 4.1 "burden of constraints for resource creation" - I feel that phrase needs more explanation [Commentor reply] tocheck [Working Group decision]

Output: This was discussed at the F2F5 and the WG agreed to change the confusing sentence to the following: How can the server make it easy for the client to create resources? See http://www.w3.org/2013/meeting/ldp/2014-04-15#LDP_Specification

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [0] Types of Messages [Abstract] Identified [Portable] Identified [Concrete]

Output: Identified


Input: [0] Message Structure [Abstract] Not Defined [Portable] Defined [Concrete]

Output: Defined


Input: [0] Conditions [Abstract] Identified [Portable] Identified [Concrete]

Output: Identified


Input: [0] Condition evaluation rules [Abstract] Not defined [Portable] Defined as far as possible [Concrete]

Output: Defined as far as possible


Input: [0] Technology used [Abstract] Not defined [Portable] Defined [Concrete]

Output: Defined


Input: [0] Message Endpoint Data [Abstract] Not defined [Portable] Not Defined [Concrete]

Output: Defined


Input: [Test Case] 5.1.a [Link To Spec] 5.1 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: built-in primitive types


Input: [Test Case] 5.1.b [Link To Spec] 5.1 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: built-in derived types


Input: [Test Case] 5.1.c [Link To Spec] 5.1 [Normative For XForms Basic] true [Normative For XForms Full] true [Description]

Output: supported primitive XML schema types in basic processors


Input: [Test Case] 5.1.d [Link To Spec] 5.1 [Normative For XForms Basic] true [Normative For XForms Full] true [Description]

Output: supported derived XML schema types in basic processors


Input: [Test Case] 5.1.e [Link To Spec] 5.1 [Normative For XForms Basic] true [Normative For XForms Full] true [Description]

Output: built-in primitive type via xsi:type


Input: [Test Case] 5.2.1.a [Link To Spec] 5.2.1 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: XForms datatypes to allow empty content - built-in primitive types


Input: [Test Case] 5.2.1.b [Link To Spec] 5.2.1 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: XForms datatypes to allow empty content - built-in derived types


Input: [Test Case] 5.2.1.c [Link To Spec] 5.2.1 [Normative For XForms Basic] true [Normative For XForms Full] true [Description]

Output: built-in data types which allow empty content for basic processors


Input: [Test Case] 5.2.2.a [Link To Spec] 5.2.2 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: listItem datatype


Input: [Test Case] 5.2.3.a [Link To Spec] 5.2.3 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: listItems datatype


Input: [Test Case] 5.2.4.a [Link To Spec] 5.2.4 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: dayTimeDuration datatype


Input: [Test Case] 5.2.5.a [Link To Spec] 5.2.5 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: yearMonthDuration datatype


Input: [Test Case] 5.2.6.a [Link To Spec] 5.2.6 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: email datatype


Input: [Test Case] 5.2.7.a [Link To Spec] 5.2.7 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: card-number datatype


Input: [Test Case] 5.2.7.b [Link To Spec] 5.2.7 [Normative For XForms Basic] false [Normative For XForms Full] true [Description]

Output: card-number datatype - credit card example


Input: [Event Name] dragstart [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [effectAllowed] uninitialized [dropEffect] none [Default Action] Initiate the drag-and-drop operation [dataTransfer]

Output: Contains source node unless a selection is being dragged, in which case it is empty


Input: [Event Name] drag [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [effectAllowed] Same as last event [dropEffect] none [Default Action] Continue the drag-and-drop operation [dataTransfer]

Output: Empty


Input: [Event Name] dragenter [Target] Immediate user selection or the body element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action] Reject immediate user selection as potential target element [dataTransfer]

Output: Empty


Input: [Event Name] dragleave [Target] Previous target element [Bubbles?] ✓ Bubbles [Cancelable?] — [effectAllowed] Same as last event [dropEffect] none [Default Action] None [dataTransfer]

Output: Empty


Input: [Event Name] dragover [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action] Reset the current drag operation to "none" [dataTransfer]

Output: Empty


Input: [Event Name] drop [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action] Varies [dataTransfer]

Output: getData() returns data set in dragstart event


Input: [Event Name] dragend [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] — [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action] Varies [dataTransfer]

Output: Empty


Input: [Commentor] LC-2834 Tim Berners-Lee (archived comment) [Working Group decision] The LDP specification brings several features such as paging and containers that are useful even in case of a read-only server. As for PATCH, everybody wants it but given the lack of a standard PATCH format and the WG timeframe it is unpractical for LDP to make PATCH mandatory. The WG is however committed to encourage support for PATCH and will do so via the LDP Best Practices and Guidelines document the WG plans to publish as a Note. As soon as a standard PATCH format is available the WG will revise the LDP spec to make use of it. [Commentor reply] tocheck [Comment]

Output: 4.5.6. You allow servers which do not support PUT or PATCH or POST. Why? A client using such a server will have no write ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET. Suggest change all to MUST, or make two levels of server, one which supports PUT and PATCH and no collections, and one which supports everything. ... 4.8 PATCH is optional. Suggest a MUST. PATCH is to first order the only thing LDP provides over WebDav. 4.8.2 MUST Suggest specify a the subset of sparql-update we use at the moment as a mandatory patch format to get basic interop, with possible later extension to other languages. ******* Something I mentioned in a mail a long time ago is the necessity of doing atomic flag (P/V) operations with a PATCH. To recap, you have to be able to do a form of DELETE triple(s) which will FAIL and prevent any corresponding INSERT from happening. This is top be able to allocate shared resources. Eg DELETE { :x :nextID 4 } INSERT DATA { ?x :nexID 5 }. Hmm. Maybe this is covered by the ETag system sufficiently. If so, the case should be given as an worked example and put in as a test case. A collaborative system which allows atomic flag setting is fundamentally more valuable than one which doesn't.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2835 Tim Berners-Lee (archived comment) [Working Group decision] OPTIONS is not required to achieve this. It could be used in cases when a client wants a low-cost means to learn more about the resource identified by the URI if it hasn't already done a GET. If it has done a GET and kept the header information, there is no need to use OPTIONS. [Commentor reply] tocheck [Comment]

Output: 4.9.1 Servers must support the OPTIONS method. Why? Should there be a basic level of functionality which any LDPR allows and which does not require OPTIONS polling? OPTIONS is expensive: another round trip. Always avoid an extra round trip if you can. We need this system to move really fast. Round trips show up as user interface sluggishness, user task inefficiency, and lost/bored users. Note that OPTIONs is resource-specific. (Unless you use some sort of wildcard extension or a POWDER label say). You have to do it for every fresh URI you find. The Linked Data operation is a GET. Is the basic operation for an LDP-capable client always OPTIONS, GET, or GET, OPTIONS? Maybe key headers can be put into the HEAD and GET response. Maybe the class of resource announced with Link: rel=type can have a URI which can be looked up itself and cached. and will give the set of features in a standard way. Suggest define a core LDP protocol which does NOT use OPTIONS, by assuming that the core functionality is enough for clients to do what they need. Clients needing extensions maybe can use OPTIONS. But maybe POWDERR should be preferred.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2812 Mark Baker (archived comment) [Working Group decision] Thank you for your feedback Mark. While we didn't go as far as rewriting section 4 entirely, we've modified it to ensure that the specification doesn't seem to be redefining HTTP which was never the intent. http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#conformance clarifies the overall relationship between LDP and HTTP; 4.6.1 was removed entirely as a result. http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#base-specs and http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpclient were added to clarify consequences of base specs and how LDP clients differ from HTTP clients. 4.11 (at risk) was removed entirely. [Commentor reply] yes [Comment]

Output: Hi. I raised this issue before, but it was never resolved to my satisfaction, so I'm raising it again now at LC. Sec 4.6.1 says "LDPR servers must remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI must result in a 404 (Not found) or 410 ". This is bad because it redefines HTTP DELETE, which already has a well defined meaning in RFC 2616. The definition in 4.6.1 is more specific than the one in 2616, and it's why you need the LDP-specific Link response header which basically tells the client that the 200 response doesn't mean what it says in RFC 2616, but instead what it says in LDP 1.0. The correct way to do this is to simply reuse the definition in 2616 so that the client knows nothing about the state of server after a DELETE has completed. I'm not familiar with the use case that requires those post conditions on DELETE, but from experience I can't imagine why a client would need to depend on this specific behaviour. Let me be clear though, my concern is *only* with the interface between client and server, not with server behaviour. If you want to define that LDP servers have to behave in a certain way, go nuts. But as soon as that information leaks into the interface, you've crossed a line, leaking implementation details so that the client is coupled not to the interface, but the implementation. The same problem with DELETE exists elsewhere in section 4 too, including with PUT, though the definition seems close enough to 2616 that I'm not sure why it's being redefined. So in addition to those concerns about section 4, I'm also concerned with the requirements on client implementations and don't understand why they're necessary. Some seem purely superfluous, such as 4.3.5, as it's part and parcel of the RDF model that resources can have multiple types (not to mention the open world assumption). The same goes for 4.3.6. 4.5.2 falls under this category too because that behaviour is just one possible path through HTTP's conflict detection mechanism. 4.5.3 and 4.5.4 seem more like BCPs that anything needing to be conformance criteria. 4.5.5 just seems like a badly phrased constraint on server implementation that has nothing to do with a client. 4.11.3.3 says that a client shouldn't invoke GET, really? Are you concerned about DoS issues like the W3C's DTD problem? http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ There's no reason to make this a criterion of correct client behaviour AFAICT 4.11.3.4 also seems like it's part and parcel with the RDF model In short, I think section 4 needs to be completely rewritten so that it; - contains no client conformance criteria - contains no interface conformance criteria In addition, the mandatory Link header should be removed so that clients won't be tempted to treat server behaviour implementation conformance criteria as interface conformance criteria; all LDP servers would be indistinguishable from Web servers. Thanks.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2833 Tim Berners-Lee (archived comment) [Working Group decision] The specification was changed to prevent silent loss of data. See http://www.w3.org/2013/meeting/ldp/2013-10-21#resolution_2 Many MAYs and SHOULDs have been changed to MUSTs as requested. See http://www.w3.org/2013/meeting/ldp/2013-10-21#resolution_3 However, imposing creation of resources via PUT is deemed unpractical at this time. See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_3 [Commentor reply] tocheck [Comment]

Output: I have comments at various levels. Two things concern me mainly, firstly that the LDP platform will support the functionality which the RWW community has been using, including tabulator-based apps, and the second if that the platform in general provide a in interoperable functionality between compliant client and server. This last is threatened mainly by the huge number of SHOULD's for the server where I would have expected MUSTs to get interoperability, and a persistent theme throughout the spec the actual behavior a client or a server can expect of the other party relies completely on out-of-band agreements. To the extent that that is true, the document does not define an interoperable system. I'll go though in document order now. [...] 4.2.9 This is an example of a complete interop gap. The server might or might not mess with your triples in any way defined elsewhere. I suggest defining a clean simple high-interop version of the server in which the server doesn't mess with or constrain the client application at all. This is a really important use case. For the RWW world, LDP storage must be generic storage which be used with any app. Maybe we can make a profile of this spec for this case, with no domain knowledge or behavior in the server. If not, we have a problem. 4.2.10 "Conservative clients"?? you already have MUST and MAY, but now (and elsewhere) you have conservative (and presumably liberal) clients. If you want to create a new conformance class Conservative Client, by all means do so, but declare it in the Conformance section and SAY WHAT YOU GET from each level of conformance. A client is not an animal tiptoeing gingerly or not into the wide world out there, it is a small hard part of a machine which either works or doesn't work. The phase occurs elsewhere too. It is a red flag. (Why would a client want to be conservative? What is risked by not being? What would a liberal client do? Does this mean the server needs to be more specified to eliminate the risk) I would strongly support as an exercise looking at a version of the spec with everything which is not mandatory removed, and see what you end up being able to do with it. 4.3.4. Broken. No guarantee that anything will work. Suggest strongly the following:- LDP Clients MUST either give no accept header or must give a header which includes at least text/turtle and has NO OTHER mime type with a higher q. LDP servers, which a GET is received on a LDPR, if text/turtle is present and there is no other mime type with a higher q, they MUST return turtle. If there is no Accept header, they must return turtle. Protocol value: If a LDP client goes a GET it will get the data in turtle. Interop is achieved. This provides interoperability and also is compatible with HTTP. It allows existing conneg software to be used, and allows LDP to work within a general conneg-based server serving other things too. 4.5.6. You allow servers which do not support PUT or PATCH or POST. Why? A client using such a server will have no write ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET. Suggest change all to MUST, or make two levels of server, one which supports PUT and PATCH and no collections, and one which supports everything. 4.5.2 Same sort of problem. Are you preventing data loss or not? Suggest yes. Clients MUST use If-match and Servers MUST implement it (which may men ignoring it in a case where you know nothing else can change the data). Protocol value: Changes from others are never overwritten. 4.5.4 A server which throws out random triples is hard as a basis for RWW applications. We must have a profile in which the server has no domain knowledge. 4.5.6 MUST allow PUT. Otherwise, what is the point? (Note that for clients which use PUT To make resources in system that looks like a unix file system, servers will have to generate intermediate directories. It is very useful for servers to be able to map a unix-like file system, for many reasons, including the isomorphisms between remote and local storage. So the use case in which the LDP server is a big unix file system but with PATCH as a performance enhancement is important. This doesn't affect the spec in any normative way I can see.) In this case, objects are not made by POST to a collection, but being mentioned in a a new file with PUT and then later PATCH. 4.5.7 MUST not SHOULD. 4.6.2 Another totally grey area. When you DELTE a resource, the server may or may not remove triples with that subject from other resources. (When you delete R, any quad R P O R2) may be deleted. This is ripe for a profile, and in that profile the value of what happens must be explained. E.G. when you delete R then R is removed from any containers, so there is no C member R *on this server* or on some other URI region. This is hairy feature, as of course, as it can't apply to triples stored on another server, so people splitting data across different servers will get unexpected results. This sounds like another protocol which needs a lot more thought. For now, suggest the LDP spec doe snot specify such behaviour, maybe flag magic triple side effects as possible extension spec in future. [...] 4.10.2.1 "Conservative clients" again. Explain the value of doing this or not doing it. 4.10.2.2 Servers MAY do it. That means clients MUST handle it. 4.10.2.3. MUST

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2836 Tim Berners-Lee (archived comment) [Working Group decision] Given the time constraints under which the WG is it is deemed unpractical to depend on defining a new response code as suggested. However, based on input from several HTTP experts the WG decided to return the first page with 200 response code on initial GET which prevents the additional roundtrip you objected to. See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_2 Move Paging information out of the RDF content into HTTP headers. See http://www.w3.org/2013/meeting/ldp/2013-09-30#resolution_2 [Commentor reply] tocheck [Comment]

Output: ######################### 4.10.2.3 303 lis a basically very unsatisfactory design because of the round trip. As this is a new spec, suggest defined 20X code meaning like a 303 but containing the representation of the thing 303d to. This has been found to a problem in LD. LDP can avoid it now. Benefit: First page back to user in one less round trip. ######################### 4.10.2.4.3 This design puts the type and next links in the data. I prefer I think using HTTP headers here as elsewhere. Page control stuff is very meta, messy to have it in with actual data. Not a problem for containers, but for normal LDPRs IMHO.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2837 Tim Berners-Lee (archived comment) [Working Group decision] Drop inlining from the spec, put it on the wish list for LDPnext See http://www.w3.org/2013/meeting/ldp/2013-09-12#resolution_2 [Commentor reply] tocheck [Comment]

Output: 4.11.1 "LDP does not provide clients with any way to detect whether or not the server is capable of inlining (all its resources or any specific resource), nor does it provide clients with any way to influence which (if any) resources are inlined in any given response." This implies cleints must all be able to handle inlining and recover from it if they didn't really want it. Need to define a protocol here properly or abandon the feature. (N3 or one of its weak imitations is obviously a clear choice for a inlined data, as it allows you to preserve the provenance, and basically explain which triples are from which resource. I understand this would frighten people at this stage.)

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2813 Ashok Malhotra (archived comment) [Working Group decision] Dispose of LC-2813 by adding a non-normative section on security setting the expectation right, pointing out that this isn't covered in LDP See http://www.w3.org/2013/meeting/ldp/2013-09-12#resolution_5 See new Security Considerations section https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#security [Commentor reply] yes [Comment]

Output: The spec says nothing about access control. Give that we are discussing read-write capabilities should we add some words like “To work with LDPRs clients must be authorized by the server and must have appropriate access control permissions”?

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2814 Ashok Malhotra (archived comment) [Working Group decision] Same as LC-2813. [Commentor reply] yes [Comment]

Output: The spec also says nothing about authentication. Should we specify some minimum level of authentication, for example: LDP servers that require authentication SHOULD consider supporting basic authentication as specified in *[**RFC2617]*** over HTTPS for the highest level of interoperability with generic clients. They MAY also support other authentication methods.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2815 Ashok Malhotra (archived comment) [Working Group decision] Added some informative content to 5.1.2 Ordering section. [Commentor reply] tocheck [Comment]

Output: We discussed that LDPCs are a subclass of LDPRs and so containers can be members of other containers. Do we say that somewhere? I could not find such a statment. Perhaps we need to add it. Also, of a container contains other containers, how would ordering work?

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2816 Ashok Malhotra (archived comment) [Working Group decision] Erroneous comment. See http://lists.w3.org/Archives/Public/public-ldp-comments/2013Aug/0005.html [Commentor reply] yes [Comment]

Output: Some comments on section 5.1.4 Ordering 1. Why is this section non-normative, given that it defines ldp:containerSortCriteria and ldp:containerSortPredicate

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2838 Tim Berners-Lee (archived comment) [Working Group decision] This is defined by the response header of the form: Link: rel="http://www.w3.org/ns/ldp#nonMemberResource" This is detailed in section 5.9.1 http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpc-5_9_1 [Commentor reply] tocheck [Comment]

Output: How does a client find the non-member-property version of a resource R?

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2839 Tim Berners-Lee (archived comment) [Working Group decision] Changed the offending text to clarify intent and use inspect rather than introspect per Tim's recommendation. [Commentor reply] tocheck [Comment]

Output: 4.10.1 "The triples in the representation of the each page are typically a subset of the triples in the resource - same subject, predicate and object." Same triples then? eh? I prefer the word "inspect" for the way "introspect" is used in the document. "Introspection" is normally looking into oneself, not into something else.

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2840 Tim Berners-Lee (archived comment) [Working Group decision] This was discussed at the F2F5 and the WG agreed to change the confusing sentence to the following: How can the server make it easy for the client to create resources? See http://www.w3.org/2013/meeting/ldp/2014-04-15#LDP_Specification [Commentor reply] tocheck [Comment]

Output: 4.1 "burden of constraints for resource creation" - I feel that phrase needs more explanation

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [function] For example, when defining an applet you could reference a space-separated list of jar files. [attribute]

Output: archive


Input: [function] This is similar to meta data, in that this can be used by the object handler as a hint to the physical size of the object data that is to be processed. [attribute]

Output: content-length


Input: [function] This URI points to the object data to be processed. This can be an absolute URI (http://www.example.com/datafiles/myinstance.mpg), or a relative URI (myinstance.mpg). If you use a relative URI, then you will need to use the xml:base attribute to define the base location of the object data. This attribute should only refer to the data to be processed. [attribute]

Output: data


Input: [function] This is used to delay the processing of the object data until such time that it is referred to by another element that requires the object data to be processed. In other words, the object data should be downloaded but should not be processed. For example, if an a element is coded to refer to the object element and the a element is activated, then the object data would be processed. [attribute]

Output: declare


Input: [function] The author can provide a text string that should be displayed while the object data is being downloaded and processed. [attribute]

Output: standby


Input: [function] Defining the mime type of the object data will assist the object handler in determining whether the object data can be processed by the user agent or if an external application needs to be launched to process the object data. [attribute]

Output: type


Input: [function] Use this attribute to define the base location of the object data. For example: http://www.example.com/datafiles/. This attribute should not be used for any other purpose. [attribute]

Output: xml:base


Input: [0] GET [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict, GSP returns undefined [LDP Collection = GSP endpoint] No conflict, GSP returns undefined [LDP Collection = GSP graph]

Output: No conflict

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] HEAD [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict; added LDP headers [LDP Collection = GSP endpoint] No conflict; added LDP headers [LDP Collection = GSP graph]

Output: No conflict; added LDP headers

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] OPTIONS [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict; added LDP headers [LDP Collection = GSP endpoint] No conflict; added LDP headers [LDP Collection = GSP graph]

Output: No conflict; added LDP headers

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] PUT [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] Conflict [LDP Collection = GSP endpoint] Conflict [LDP Collection = GSP graph]

Output: No conflict

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] POST [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] Conflict [LDP Collection = GSP endpoint] Conflict [LDP Collection = GSP graph]

Output: No conflict? Different functionality is to be expected, but do not influence each other

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] DELETE [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict [LDP Collection = GSP endpoint] No conflict [LDP Collection = GSP graph]

Output: No conflict

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [0] PATCH [LDP Resource = GSP graph] No conflict [LDP Resource = GSP endpoint] No conflict [LDP Collection = GSP endpoint] No conflict [LDP Collection = GSP graph]

Output: Conflict; changes through GSP can break consistency in LDPC

Difference between revisions of "Linked Data Platform (LDP) vs SPARQL Graph Store HTTP Protocol (GSP)" - Linked Data Platform


Input: [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Contains source node unless a selection is being dragged, in which case it is empty [effectAllowed] uninitialized [dropEffect] none [Default Action] Initiate the drag-and-drop operation [Event Name]

Output: dragstart


Input: [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] none [Default Action] Continue the drag-and-drop operation [Event Name]

Output: drag


Input: [Target] Immediate user selection or the body element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action] Reject immediate user selection as potential target element [Event Name]

Output: dragenter


Input: [Target] Previous target element [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] none [Default Action] None [Event Name]

Output: dragleave


Input: [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action] Reset the current drag operation to "none" [Event Name]

Output: dragover


Input: [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] getData() returns data set in dragstart event [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action] Varies [Event Name]

Output: drop


Input: [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action] Varies [Event Name]

Output: dragend


Input: [Page-margin box] top-left-corner [‘vertical-align’] middle [‘text-align’]

Output: right

Table 2. Default values for Page-Margin Boxes


Input: [Page-margin box] top-left [‘vertical-align’] middle [‘text-align’]

Output: left


Input: [Page-margin box] top-center [‘vertical-align’] middle [‘text-align’]

Output: center


Input: [Page-margin box] top-right [‘vertical-align’] middle [‘text-align’]

Output: right


Input: [Page-margin box] top-right-corner [‘vertical-align’] middle [‘text-align’]

Output: left


Input: [Page-margin box] left-top [‘vertical-align’] top [‘text-align’]

Output: center


Input: [Page-margin box] left-middle [‘vertical-align’] middle [‘text-align’]

Output: center


Input: [Page-margin box] left-bottom [‘vertical-align’] bottom [‘text-align’]

Output: center


Input: [Page-margin box] right-top [‘vertical-align’] top [‘text-align’]

Output: center


Input: [Page-margin box] right-middle [‘vertical-align’] middle [‘text-align’]

Output: center


Input: [Page-margin box] right-bottom [‘vertical-align’] bottom [‘text-align’]

Output: center


Input: [Page-margin box] bottom-left-corner [‘vertical-align’] middle [‘text-align’]

Output: right


Input: [Page-margin box] bottom-left [‘vertical-align’] middle [‘text-align’]

Output: left


Input: [Page-margin box] bottom-center [‘vertical-align’] middle [‘text-align’]

Output: center


Input: [Page-margin box] bottom-right [‘vertical-align’] middle [‘text-align’]

Output: right


Input: [Page-margin box] bottom-right-corner [‘vertical-align’] middle [‘text-align’]

Output: left


Input: [0] Types of Messages [Portable] Identified [Concrete] Identified [Abstract]

Output: Identified


Input: [0] Message Structure [Portable] Defined [Concrete] Defined [Abstract]

Output: Not Defined


Input: [0] Conditions [Portable] Identified [Concrete] Identified [Abstract]

Output: Identified


Input: [0] Condition evaluation rules [Portable] Defined as far as possible [Concrete] Defined as far as possible [Abstract]

Output: Not defined


Input: [0] Technology used [Portable] Defined [Concrete] Defined [Abstract]

Output: Not defined


Input: [0] Message Endpoint Data [Portable] Not Defined [Concrete] Defined [Abstract]

Output: Not defined


Input: [Operation] encrypt [Parameters] AesGcmParams [Result]

Output: ArrayBuffer


Input: [Operation] decrypt [Parameters] AesGcmParams [Result]

Output: ArrayBuffer


Input: [Operation] generateKey [Parameters] AesKeyGenParams [Result]

Output: CryptoKey


Input: [Operation] importKey [Parameters] None [Result]

Output: CryptoKey


Input: [Operation] exportKey [Parameters] None [Result]

Output: object


Input: [Operation] get key length [Parameters] AesDerivedKeyParams [Result]

Output: Integer


Input: [Component] Address [Specification priority] Nice to [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Address, email [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Alpha string, simple [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Configure & Return


Input: [Component] Alphanumeric string, non-fixed [Specification priority] Nice to [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Alphanumeric string, sectioned [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Alphanumeric string, simple [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Configure & Return


Input: [Component] Browsable action list [Specification priority] Should [Task vs. Template] Template [Specification level]

Output: Return only


Input: [Component] Browsable selection list [Specification priority] Should [Task vs. Template] Template [Specification level]

Output: Return only


Input: [Component] Credit card information [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Confirmation & correction dialog [Specification priority] Should [Task vs. Template] Template [Specification level]

Output: Return only


Input: [Component] Currency [Specification priority] Must [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Date, context-compensating [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Date, fully-specified [Specification priority] Must [Task vs. Template] Task [Specification level]

Output: Configure & Return


Input: [Component] Date, partially-specified [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Configure & Return


Input: [Component] Digit string, sectioned [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Digit string, simple [Specification priority] Must [Task vs. Template] Task [Specification level]

Output: Configure & Return


Input: [Component] Duration [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Error-recovery dialog, simple [Specification priority] Should [Task vs. Template] Template [Specification level]

Output: Configure & Return


Input: [Component] Menu [Specification priority] Must [Task vs. Template] Template [Specification level]

Output: Return only


Input: [Component] Multiple choice selections [Specification priority] Nice to [Task vs. Template] Template [Specification level]

Output: Return only


Input: [Component] Name, spelled [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Name, spoken & spelled [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Natural numbers [Specification priority] Must [Task vs. Template] Task [Specification level]

Output: Configure & Return


Input: [Component] Postal code [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Telephone number [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Time [Specification priority] Must [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Time range [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] URL [Specification priority] Should [Task vs. Template] Task [Specification level]

Output: Return only


Input: [Component] Yes/No [Specification priority] Must [Task vs. Template] Task [Specification level]

Output: Configure & Return


Input: [Expected Values] alternativeText [Augmented Access Mode] Textual [Description] alternative text is provided for visual content (e.g., the HTML alt attribute).

Output: Visual

Source Access Mode (before augmentation)


Input: [Expected Values] longDescription [Augmented Access Mode] Textual [Description] descriptions are provided for image-based visual content and/or complex structures such as tables, mathematics, diagrams or charts.

Output: Visual

Source Access Mode (before augmentation)


Input: [Expected Values] ChemML laTex MathML [Augmented Access Mode] Textual [Description] The use of one of these specific ASCII/XML encodings for mathematics or chemistry. These can have extensions specified, but are rarely needed.

Output: Visual

Source Access Mode (before augmentation)


Input: [Expected Values] transcript [Augmented Access Mode] Textual [Description] The addition of a separate transcript to convey the meaning of the audio.

Output: Auditory

Source Access Mode (before augmentation)


Input: [Expected Values] captions [Augmented Access Mode] Visual [Description] The addition of synchronized text (closed captions) to convey the meaning of the audio. Note that while many captions may be implemented as textual in the transport, users think of them as being a visual appearance.

Output: Auditory

Source Access Mode (before augmentation)


Input: [Expected Values] signLanguage [Augmented Access Mode] Visual [Description] The presentation of audio in sign language in the visual presentation. The most likely extension is /sgn-en-us or other ISO 639 sign language code.

Output: Auditory

Source Access Mode (before augmentation)


Input: [Expected Values] audioDescription [Augmented Access Mode] Auditory [Description] Audio descriptions are available (e.g., via the HTML5 track element). Common extensions are for the various "onImage" refinements noted above.

Output: Visual

Source Access Mode (before augmentation)


Input: [Expected Values] braille [Augmented Access Mode] Tactile [Description] braille content or alternative is available (e.g., eBraille or print braille) This can have extensions for the different types of braille, /ASCII, /music, /math, /chem or /nemeth) (also consider /contracted and /gradeII or other nomenclature... pretty open)

Output: Visual or Textual

Source Access Mode (before augmentation)


Input: [Expected Values] tactileGraphic [Augmented Access Mode] Tactile [Description] tactile graphics have been provided, as described in the BANA Guidelines and Standards for Tactile Graphics.

Output: Visual

Source Access Mode (before augmentation)


Input: [Expected Values] tactileObject [Augmented Access Mode] Tactile [Description] tactile 3D objects have been defined and a 3D object or instructions to build one are available.

Output: Visual

Source Access Mode (before augmentation)


Input: [Event name] loadstart [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent begins fetching the media data, synchronously during the load() method call. [Preconditions]

Output: networkState equals LOADING


Input: [Event name] progress [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent is fetching media data. [Preconditions]

Output: networkState is more than EMPTY and less than LOADED


Input: [Event name] loadedmetadata [Interface] Event [Dispatched when...] The user agent is fetching media data, and the media resource's metadata has just been received. [Preconditions]

Output: networkState equals LOADED_METADATA


Input: [Event name] loadedfirstframe [Interface] Event [Dispatched when...] The user agent is fetching media data, and the media resource's first frame has just been received. [Preconditions]

Output: networkState equals LOADED_FIRST_FRAME


Input: [Event name] load [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent finishes downloading the entire media resource. [Preconditions]

Output: networkState equals LOADED


Input: [Event name] abort [Interface] ProgressEvent [PROGRESS] [Dispatched when...] The user agent stops fetching the media data before it is completely downloaded. This can be fired synchronously during the load() method call. [Preconditions]

Output: error is an object with the code MEDIA_ERR_ABORTED. networkState equals either EMPTY or LOADED, depending on when the download was aborted.


Input: [Event name] error [Interface] ProgressEvent [PROGRESS] [Dispatched when...] An error occurs while fetching the media data. [Preconditions]

Output: error is an object with the code MEDIA_ERR_NETWORK_ERROR or higher. networkState equals either EMPTY or LOADED, depending on when the download was aborted.


Input: [Event name] emptied [Interface] Event [Dispatched when...] A media element whose networkState was previously not in the EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was reinvoked, in which case it is fired synchronously during the load() method call). [Preconditions]

Output: networkState is EMPTY; all the DOM attributes are in their initial states.


Input: [Event name] play [Interface] Event [Dispatched when...] Playback has begun. Fired after the play method has returned. [Preconditions]

Output: paused is newly false.


Input: [Event name] pause [Interface] Event [Dispatched when...] Playback has been paused. Fired after the pause method has returned. [Preconditions]

Output: paused is newly true.


Input: [Event name] waiting [Interface] Event [Dispatched when...] Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course. [Preconditions]

Output: readyState is either DATA_UNAVAILABLE or CAN_SHOW_CURRENT_FRAME, and paused is false. Either seeking is true, or the current playback position is not contained in any of the ranges in buffered. It is possible for playback to stop for two other reasons without paused being false, but those two reasons do not fire this event: maybe playback ended, or playback stopped due to errors.


Input: [Event name] ended [Interface] Event [Dispatched when...] Playback has stopped because the end of the media resource was reached. [Preconditions]

Output: currentTime equals the effective end; ended is true.


Input: [Event name] dataunavailable [Interface] Event [Dispatched when...] The user agent cannot render the data at the current playback position because data for the current frame is not immediately available. [Preconditions]

Output: The readyState attribute is newly equal to DATA_UNAVAILABLE.


Input: [Event name] canshowcurrentframe [Interface] Event [Dispatched when...] The user agent cannot render the data after the current playback position because data for the next frame is not immediately available. [Preconditions]

Output: The readyState attribute is newly equal to CAN_SHOW_CURRENT_FRAME.


Input: [Event name] canplay [Interface] Event [Dispatched when...] The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content. [Preconditions]

Output: The readyState attribute is newly equal to CAN_PLAY.


Input: [Event name] canplaythrough [Interface] Event [Dispatched when...] The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering. [Preconditions]

Output: The readyState attribute is newly equal to CAN_PLAY_THROUGH.


Input: [Expected Values] alternativeText Visual [Description] alternative text is provided for visual content (e.g., the HTML alt attribute). [Augmented Access Mode]

Output: Textual


Input: [Expected Values] longDescription Visual [Description] descriptions are provided for image-based visual content and/or complex structures such as tables, mathematics, diagrams or charts. [Augmented Access Mode]

Output: Textual


Input: [Expected Values] ChemML laTex MathML Visual [Description] The use of one of these specific ASCII/XML encodings for mathematics or chemistry. These can have extensions specified, but are rarely needed. [Augmented Access Mode]

Output: Textual


Input: [Expected Values] transcript Auditory [Description] The addition of a separate transcript to convey the meaning of the audio. [Augmented Access Mode]

Output: Textual


Input: [Expected Values] captions Auditory [Description] The addition of synchronized text (closed captions) to convey the meaning of the audio. Note that while many captions may be implemented as textual in the transport, users think of them as being a visual appearance. [Augmented Access Mode]

Output: Visual


Input: [Expected Values] signLanguage Auditory [Description] The presentation of audio in sign language in the visual presentation. The most likely extension is /sgn-en-us or other ISO 639 sign language code. [Augmented Access Mode]

Output: Visual


Input: [Expected Values] audioDescription Visual [Description] Audio descriptions are available (e.g., via the HTML5 track element). Common extensions are for the various "onImage" refinements noted above. [Augmented Access Mode]

Output: Auditory


Input: [Expected Values] braille Visual or Textual [Description] braille content or alternative is available (e.g., eBraille or print braille) This can have extensions for the different types of braille, /ASCII, /music, /math, /chem or /nemeth) (also consider /contracted and /gradeII or other nomenclature... pretty open) [Augmented Access Mode]

Output: Tactile


Input: [Expected Values] tactileGraphic Visual [Description] tactile graphics have been provided, as described in the BANA Guidelines and Standards for Tactile Graphics. [Augmented Access Mode]

Output: Tactile


Input: [Expected Values] tactileObject Visual [Description] tactile 3D objects have been defined and a 3D object or instructions to build one are available. [Augmented Access Mode]

Output: Tactile


Input: [Responder] Roy Fielding [Objections to Option A]

Output: I object to this definition of "collects": data collection is inherently about retaining (or giving to someone else) that which is collected. Data that merely comes within control is not collecting: an Internet router isn't collecting data when it forwards it between two peers. I described that extensively in a message to the list on 23 May 2012, which I will recap here. The regulatory bodies use the term "data collection" extensively without actually defining it. As near as I can tell, they rely on the commonly established usage of the term for statistical surveys, something which the government is very familiar with (census) and frequently regulates. "Data collection is the process of gathering data." [2] and "gathering" is itself defined as collection (circular) or as the act of assembling a group of things together in one place. I think we all should understand that collection implies gathering together and at least some form of retention (i.e., either retention by the party doing the collecting, or retention by some other party that received what was collected). "I have a large seashell collection which I keep scattered on the beaches all over the world... maybe you've seen it." -- Steven Wright [1] The above joke by Steven Wright depends on the audience knowing that. We collect seashells by taking them off the beach, not by merely walking by them. We collect photos of seashells by taking each one's picture and retaining that picture, not by snapping the shot and then deleting it from memory. As a technical matter, assigning a pseudo-ID to a user agent via a cookie that is derived from a random source, perhaps combined with codes for algorithmic validation, and merely receiving that cookie in later requests, is not by itself data collection. Data collection would be retaining the cookie value along with the request data, or gathering the data from multiple requests over time in a way that can be traced back to that cookie. This distinction is important because there are many uses of cookies that are not for the purpose of tracking, even though the value is unique per user agent. I only object to the other definitions to the extent they rely on this incorrect definition of collects. [1] http://www.funnyordie.com/videos/a024670721/steven-wright-standup-from-standupfan [2] http://stats.oecd.org/glossary/detail.asp?ID=534

Results of Questionnaire [Call for Objections] Collect/Retain/Use/Share - Web-Based Straw-poll and Balloting System


Input: [Responder] Mike O'Neill [Objections to Option A]

Output: I object to Option A because collecting has to be purposeful, data could "come within control" without any attempt to track. If the data is actively retained after the network interaction then that is another matter, which is why I support Option B more. I also think "merely forwarding" counts as using, because the forwarding must have been for some purpose. I do not like a separate definition of "facilitates" because it weakens the prohibition against "sharing" (when any party sees DNT set).

Results of Questionnaire [Call for Objections] Collect/Retain/Use/Share - Web-Based Straw-poll and Balloting System


Input: [Responder] David Singer [Objections to Option A]

Output: It's silly to say I collected something if it was sent to me without my asking. This is problematic, in that if we write 'must not collect' this is unimplementable. Perhaps we would only use 'retain'?

Results of Questionnaire [Call for Objections] Collect/Retain/Use/Share - Web-Based Straw-poll and Balloting System


Input: [Responder] Rob van Eijk [Objections to Option A]

Output: I object to Option A because it mixes a definition of party with processing of data.

Results of Questionnaire [Call for Objections] Collect/Retain/Use/Share - Web-Based Straw-poll and Balloting System


Input: [Responder] Jack Hobaugh [Objections to Option A]

Output: In general, I object to the porting of a TCS compliance definition into the TPE. I feel strongly that the TPE should remain a pure protocol and technical specification document. Some have contended that some TCS definitions are needed in the TPE in order for the consumer to understand the choice that the consumer is making regarding the DNT signal. This is simply not the case. A technical specification need only specify the requests and responses necessary for a DNT protocol to be implemented in a scalable and implementable solution across all browsers and the servers called. The intended audience for the TPE is made up of technical implementers such as software engineers, developers, and programmers. To be clear, the TPE should not take on the responsibility of informing consumers and attorneys regarding a policy or compliance choice but instead should inform the technical community on how to implement the technical solution. The compliance specification for the DNT signal should be left to the compliance regime, whether it is a national compliance regime, a W3C-based compliance regime or an industry-based compliance regime. Porting definitions from a particular compliance regime into the TPE only serves to provide an incomplete and confusing picture to the software engineers, developers, and programmers who will be tasked with implementing the technical protocol.

Results of Questionnaire [Call for Objections] Collect/Retain/Use/Share - Web-Based Straw-poll and Balloting System


Input: [Responder] Alan Chapell [Objections to Option A]

Output: I respectfully object to the inclusion of any of these definitions. It is unclear that any of these terms need to be defined in order to complete the TPE. Moreover, these definitions have dependencies with regard to the definitions of both Party and Tracking which were addressed in a CFO weeks ago. We seem to be doing things in reverse order here. As a standards body, I would hope the W3C would recognize that any terms we choose to define here will have an impact downstream as legislators and regulators around the world will be tempted to utilize such terms. With that in mind, the definition of "facilitates" should not be included as it conflates the concept of "data collection" with the concept of "tracking."

Results of Questionnaire [Call for Objections] Collect/Retain/Use/Share - Web-Based Straw-poll and Balloting System


Input: [Event Name] dragstart [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Contains source node unless a selection is being dragged, in which case it is empty [effectAllowed] uninitialized [dropEffect] none [Default Action]

Output: Initiate the drag-and-drop operation


Input: [Event Name] drag [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] none [Default Action]

Output: Continue the drag-and-drop operation


Input: [Event Name] dragenter [Target] Immediate user selection or the body element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action]

Output: Reject immediate user selection as potential target element


Input: [Event Name] dragleave [Target] Previous target element [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] none [Default Action]


Input: [Event Name] dragover [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action]

Output: Reset the current drag operation to "none"


Input: [Event Name] drop [Target] Current target element [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] getData() returns data set in dragstart event [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action]

Output: Varies


Input: [Event Name] dragend [Target] Source node [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action]

Output: Varies


Input: [0] The cells in [1] this table [2]

Output: should go


Input: [0] green when [1] you hover [2]

Output: the pointing


Input: [0] The rows in [1] this table [2]

Output: should go


Input: [0] dark green [1] when the [2]

Output: pointing device


Input: [0] is over the [1] five pixel [2]

Output: border spacing


Input: [0] Including here, [2]

Output: blank cells.


Input: [Event name] loadstart [Dispatched when...]

Output: The user agent begins looking for media data, as part of the resource selection algorithm.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] progress [Dispatched when...]

Output: The user agent is fetching media data.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] suspend [Dispatched when...]

Output: The user agent is intentionally not currently fetching media data, but does not have the entire media resource downloaded.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] abort [Dispatched when...]

Output: The user agent stops fetching the media data before it is completely downloaded, but not due to an error.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] error [Dispatched when...]

Output: An error occurs while fetching the media data.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] emptied [Dispatched when...]

Output: A media element whose networkState was previously not in the NETWORK_EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was invoked while the resource selection algorithm was already running).

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] stalled [Dispatched when...]

Output: The user agent is trying to fetch media data, but data is unexpectedly not forthcoming.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] play [Dispatched when...]

Output: Playback has begun. Fired after the play() method has returned, or when the autoplay attribute has caused playback to begin.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] pause [Dispatched when...]

Output: Playback has been paused. Fired after the pause() method has returned.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] loadedmetadata [Dispatched when...]

Output: The user agent has just determined the duration and dimensions of the media resource

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] loadeddata [Dispatched when...]

Output: The user agent can render the media data at the current playback position for the first time.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] waiting [Dispatched when...]

Output: Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] playing [Dispatched when...]

Output: Playback has started.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] canplay [Dispatched when...]

Output: The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] canplaythrough [Dispatched when...]

Output: The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] seeking [Dispatched when...]

Output: The seeking IDL attribute changed to true and the seek operation is taking long enough that the user agent has time to fire the event.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] seeked [Dispatched when...]

Output: The seeking IDL attribute changed to false.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] timeupdate [Dispatched when...]

Output: The current playback position changed as part of normal playback or in an especially interesting way, for example discontinuously.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] ended [Dispatched when...]

Output: Playback has stopped because the end of the media resource was reached.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] ratechange [Dispatched when...]

Output: Either the defaultPlaybackRate or the playbackRate attribute has just been updated.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] durationchange [Dispatched when...]

Output: The duration attribute has just been updated.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Event name] volumechange [Dispatched when...]

Output: Either the volume attribute or the muted attribute has changed. Fired after the relevant attribute's setter has returned.

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Id:Title] wd-1 : QA Editorial Comments [State] agreed [Type] editorial [Ack.]

Output: No reply from reviewer


Input: [Id:Title] wd-2 : Normative vs. Informative [State] agreed [Type] editorial [Ack.]

Output: No reply from reviewer


Input: [Id:Title] wd-4 : Incomplete Conformance Section [State] agreed [Type] editorial [Ack.]

Output: No reply from reviewer


Input: [Id:Title] wd-5 : The schema designator URI should be dereferenceable [State] agreed [Type] request [Ack.]

Output: No reply from reviewer


Input: [Id:Title] wd-6 : The Schema URI SHOULD be used [State] agreed [Type] request [Ack.]

Output: No reply from reviewer


Input: [Id:Title] wd-7 : Compatibility with XPath [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-8 : Drop or Change Query Use Case [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-9 : Change syntax for model group step [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-10 : Support for redefined component's predecessor [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-11 : Specify a canonical namespace prefix? [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-12 : Allow type(*) and element(*)? [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-13 : Interaction of expanded traversals with // [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-15 : Interaction of elided steps with extended traversals [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-16 : Short for syntax for type(qname) [State] agreed [Type] request [Ack.]

Output: No response to reviewer


Input: [Id:Title] wd-17 : SCP ambiguity, sigh [State] agreed [Type] proposal [Ack.]

Output: No response to reviewer


Input: [Event Name] dragstart [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Contains source node unless a selection is being dragged, in which case it is empty [effectAllowed] uninitialized [dropEffect] none [Default Action] Initiate the drag-and-drop operation [Target]

Output: Source node


Input: [Event Name] drag [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] none [Default Action] Continue the drag-and-drop operation [Target]

Output: Source node


Input: [Event Name] dragenter [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action] Reject immediate user selection as potential target element [Target]

Output: Immediate user selection or the body element


Input: [Event Name] dragleave [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] none [Default Action] None [Target]

Output: Previous target element


Input: [Event Name] dragover [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Based on effectAllowed value [Default Action] Reset the current drag operation to "none" [Target]

Output: Current target element


Input: [Event Name] drop [Bubbles?] ✓ Bubbles [Cancelable?] ✓ Cancelable [dataTransfer] getData() returns data set in dragstart event [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action] Varies [Target]

Output: Current target element


Input: [Event Name] dragend [Bubbles?] ✓ Bubbles [Cancelable?] — [dataTransfer] Empty [effectAllowed] Same as last event [dropEffect] Current drag operation [Default Action] Varies [Target]

Output: Source node


Input: [Dispatched when...] The user agent begins looking for media data, as part of the resource selection algorithm. [Event name]

Output: loadstart

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The user agent is fetching media data. [Event name]

Output: progress

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The user agent is intentionally not currently fetching media data, but does not have the entire media resource downloaded. [Event name]

Output: suspend

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The user agent stops fetching the media data before it is completely downloaded, but not due to an error. [Event name]

Output: abort

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] An error occurs while fetching the media data. [Event name]

Output: error

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] A media element whose networkState was previously not in the NETWORK_EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was invoked while the resource selection algorithm was already running). [Event name]

Output: emptied

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The user agent is trying to fetch media data, but data is unexpectedly not forthcoming. [Event name]

Output: stalled

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] Playback has begun. Fired after the play() method has returned, or when the autoplay attribute has caused playback to begin. [Event name]

Output: play

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] Playback has been paused. Fired after the pause() method has returned. [Event name]

Output: pause

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The user agent has just determined the duration and dimensions of the media resource [Event name]

Output: loadedmetadata

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The user agent can render the media data at the current playback position for the first time. [Event name]

Output: loadeddata

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course. [Event name]

Output: waiting

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] Playback has started. [Event name]

Output: playing

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The user agent can resume playback of the media data, but estimates that if playback were to be started now, the media resource could not be rendered at the current playback rate up to its end without having to stop for further buffering of content. [Event name]

Output: canplay

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The user agent estimates that if playback were to be started now, the media resource could be rendered at the current playback rate all the way to its end without having to stop for further buffering. [Event name]

Output: canplaythrough

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The seeking IDL attribute changed to true and the seek operation is taking long enough that the user agent has time to fire the event. [Event name]

Output: seeking

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The seeking IDL attribute changed to false. [Event name]

Output: seeked

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The current playback position changed as part of normal playback or in an especially interesting way, for example discontinuously. [Event name]

Output: timeupdate

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] Playback has stopped because the end of the media resource was reached. [Event name]

Output: ended

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] Either the defaultPlaybackRate or the playbackRate attribute has just been updated. [Event name]

Output: ratechange

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] The duration attribute has just been updated. [Event name]

Output: durationchange

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Dispatched when...] Either the volume attribute or the muted attribute has changed. Fired after the relevant attribute's setter has returned. [Event name]

Output: volumechange

Difference between revisions of "HTML/Elements/audio" - W3C Wiki


Input: [Commentor] LC-2834 Tim Berners-Lee (archived comment) [Comment] 4.5.6. You allow servers which do not support PUT or PATCH or POST. Why? A client using such a server will have no write ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET. Suggest change all to MUST, or make two levels of server, one which supports PUT and PATCH and no collections, and one which supports everything. ... 4.8 PATCH is optional. Suggest a MUST. PATCH is to first order the only thing LDP provides over WebDav. 4.8.2 MUST Suggest specify a the subset of sparql-update we use at the moment as a mandatory patch format to get basic interop, with possible later extension to other languages. ******* Something I mentioned in a mail a long time ago is the necessity of doing atomic flag (P/V) operations with a PATCH. To recap, you have to be able to do a form of DELETE triple(s) which will FAIL and prevent any corresponding INSERT from happening. This is top be able to allocate shared resources. Eg DELETE { :x :nextID 4 } INSERT DATA { ?x :nexID 5 }. Hmm. Maybe this is covered by the ETag system sufficiently. If so, the case should be given as an worked example and put in as a test case. A collaborative system which allows atomic flag setting is fundamentally more valuable than one which doesn't. [Working Group decision] The LDP specification brings several features such as paging and containers that are useful even in case of a read-only server. As for PATCH, everybody wants it but given the lack of a standard PATCH format and the WG timeframe it is unpractical for LDP to make PATCH mandatory. The WG is however committed to encourage support for PATCH and will do so via the LDP Best Practices and Guidelines document the WG plans to publish as a Note. As soon as a standard PATCH format is available the WG will revise the LDP spec to make use of it. [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2835 Tim Berners-Lee (archived comment) [Comment] 4.9.1 Servers must support the OPTIONS method. Why? Should there be a basic level of functionality which any LDPR allows and which does not require OPTIONS polling? OPTIONS is expensive: another round trip. Always avoid an extra round trip if you can. We need this system to move really fast. Round trips show up as user interface sluggishness, user task inefficiency, and lost/bored users. Note that OPTIONs is resource-specific. (Unless you use some sort of wildcard extension or a POWDER label say). You have to do it for every fresh URI you find. The Linked Data operation is a GET. Is the basic operation for an LDP-capable client always OPTIONS, GET, or GET, OPTIONS? Maybe key headers can be put into the HEAD and GET response. Maybe the class of resource announced with Link: rel=type can have a URI which can be looked up itself and cached. and will give the set of features in a standard way. Suggest define a core LDP protocol which does NOT use OPTIONS, by assuming that the core functionality is enough for clients to do what they need. Clients needing extensions maybe can use OPTIONS. But maybe POWDERR should be preferred. [Working Group decision] OPTIONS is not required to achieve this. It could be used in cases when a client wants a low-cost means to learn more about the resource identified by the URI if it hasn't already done a GET. If it has done a GET and kept the header information, there is no need to use OPTIONS. [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2812 Mark Baker (archived comment) [Comment] Hi. I raised this issue before, but it was never resolved to my satisfaction, so I'm raising it again now at LC. Sec 4.6.1 says "LDPR servers must remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI must result in a 404 (Not found) or 410 ". This is bad because it redefines HTTP DELETE, which already has a well defined meaning in RFC 2616. The definition in 4.6.1 is more specific than the one in 2616, and it's why you need the LDP-specific Link response header which basically tells the client that the 200 response doesn't mean what it says in RFC 2616, but instead what it says in LDP 1.0. The correct way to do this is to simply reuse the definition in 2616 so that the client knows nothing about the state of server after a DELETE has completed. I'm not familiar with the use case that requires those post conditions on DELETE, but from experience I can't imagine why a client would need to depend on this specific behaviour. Let me be clear though, my concern is *only* with the interface between client and server, not with server behaviour. If you want to define that LDP servers have to behave in a certain way, go nuts. But as soon as that information leaks into the interface, you've crossed a line, leaking implementation details so that the client is coupled not to the interface, but the implementation. The same problem with DELETE exists elsewhere in section 4 too, including with PUT, though the definition seems close enough to 2616 that I'm not sure why it's being redefined. So in addition to those concerns about section 4, I'm also concerned with the requirements on client implementations and don't understand why they're necessary. Some seem purely superfluous, such as 4.3.5, as it's part and parcel of the RDF model that resources can have multiple types (not to mention the open world assumption). The same goes for 4.3.6. 4.5.2 falls under this category too because that behaviour is just one possible path through HTTP's conflict detection mechanism. 4.5.3 and 4.5.4 seem more like BCPs that anything needing to be conformance criteria. 4.5.5 just seems like a badly phrased constraint on server implementation that has nothing to do with a client. 4.11.3.3 says that a client shouldn't invoke GET, really? Are you concerned about DoS issues like the W3C's DTD problem? http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/ There's no reason to make this a criterion of correct client behaviour AFAICT 4.11.3.4 also seems like it's part and parcel with the RDF model In short, I think section 4 needs to be completely rewritten so that it; - contains no client conformance criteria - contains no interface conformance criteria In addition, the mandatory Link header should be removed so that clients won't be tempted to treat server behaviour implementation conformance criteria as interface conformance criteria; all LDP servers would be indistinguishable from Web servers. Thanks. [Working Group decision] Thank you for your feedback Mark. While we didn't go as far as rewriting section 4 entirely, we've modified it to ensure that the specification doesn't seem to be redefining HTTP which was never the intent. http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#conformance clarifies the overall relationship between LDP and HTTP; 4.6.1 was removed entirely as a result. http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#base-specs and http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpclient were added to clarify consequences of base specs and how LDP clients differ from HTTP clients. 4.11 (at risk) was removed entirely. [Commentor reply]

Output: yes

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2833 Tim Berners-Lee (archived comment) [Comment] I have comments at various levels. Two things concern me mainly, firstly that the LDP platform will support the functionality which the RWW community has been using, including tabulator-based apps, and the second if that the platform in general provide a in interoperable functionality between compliant client and server. This last is threatened mainly by the huge number of SHOULD's for the server where I would have expected MUSTs to get interoperability, and a persistent theme throughout the spec the actual behavior a client or a server can expect of the other party relies completely on out-of-band agreements. To the extent that that is true, the document does not define an interoperable system. I'll go though in document order now. [...] 4.2.9 This is an example of a complete interop gap. The server might or might not mess with your triples in any way defined elsewhere. I suggest defining a clean simple high-interop version of the server in which the server doesn't mess with or constrain the client application at all. This is a really important use case. For the RWW world, LDP storage must be generic storage which be used with any app. Maybe we can make a profile of this spec for this case, with no domain knowledge or behavior in the server. If not, we have a problem. 4.2.10 "Conservative clients"?? you already have MUST and MAY, but now (and elsewhere) you have conservative (and presumably liberal) clients. If you want to create a new conformance class Conservative Client, by all means do so, but declare it in the Conformance section and SAY WHAT YOU GET from each level of conformance. A client is not an animal tiptoeing gingerly or not into the wide world out there, it is a small hard part of a machine which either works or doesn't work. The phase occurs elsewhere too. It is a red flag. (Why would a client want to be conservative? What is risked by not being? What would a liberal client do? Does this mean the server needs to be more specified to eliminate the risk) I would strongly support as an exercise looking at a version of the spec with everything which is not mandatory removed, and see what you end up being able to do with it. 4.3.4. Broken. No guarantee that anything will work. Suggest strongly the following:- LDP Clients MUST either give no accept header or must give a header which includes at least text/turtle and has NO OTHER mime type with a higher q. LDP servers, which a GET is received on a LDPR, if text/turtle is present and there is no other mime type with a higher q, they MUST return turtle. If there is no Accept header, they must return turtle. Protocol value: If a LDP client goes a GET it will get the data in turtle. Interop is achieved. This provides interoperability and also is compatible with HTTP. It allows existing conneg software to be used, and allows LDP to work within a general conneg-based server serving other things too. 4.5.6. You allow servers which do not support PUT or PATCH or POST. Why? A client using such a server will have no write ability at all, and so your spec as a protocol delivers zero value on top of HTTP GET. Suggest change all to MUST, or make two levels of server, one which supports PUT and PATCH and no collections, and one which supports everything. 4.5.2 Same sort of problem. Are you preventing data loss or not? Suggest yes. Clients MUST use If-match and Servers MUST implement it (which may men ignoring it in a case where you know nothing else can change the data). Protocol value: Changes from others are never overwritten. 4.5.4 A server which throws out random triples is hard as a basis for RWW applications. We must have a profile in which the server has no domain knowledge. 4.5.6 MUST allow PUT. Otherwise, what is the point? (Note that for clients which use PUT To make resources in system that looks like a unix file system, servers will have to generate intermediate directories. It is very useful for servers to be able to map a unix-like file system, for many reasons, including the isomorphisms between remote and local storage. So the use case in which the LDP server is a big unix file system but with PATCH as a performance enhancement is important. This doesn't affect the spec in any normative way I can see.) In this case, objects are not made by POST to a collection, but being mentioned in a a new file with PUT and then later PATCH. 4.5.7 MUST not SHOULD. 4.6.2 Another totally grey area. When you DELTE a resource, the server may or may not remove triples with that subject from other resources. (When you delete R, any quad R P O R2) may be deleted. This is ripe for a profile, and in that profile the value of what happens must be explained. E.G. when you delete R then R is removed from any containers, so there is no C member R *on this server* or on some other URI region. This is hairy feature, as of course, as it can't apply to triples stored on another server, so people splitting data across different servers will get unexpected results. This sounds like another protocol which needs a lot more thought. For now, suggest the LDP spec doe snot specify such behaviour, maybe flag magic triple side effects as possible extension spec in future. [...] 4.10.2.1 "Conservative clients" again. Explain the value of doing this or not doing it. 4.10.2.2 Servers MAY do it. That means clients MUST handle it. 4.10.2.3. MUST [Working Group decision] The specification was changed to prevent silent loss of data. See http://www.w3.org/2013/meeting/ldp/2013-10-21#resolution_2 Many MAYs and SHOULDs have been changed to MUSTs as requested. See http://www.w3.org/2013/meeting/ldp/2013-10-21#resolution_3 However, imposing creation of resources via PUT is deemed unpractical at this time. See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_3 [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2836 Tim Berners-Lee (archived comment) [Comment] ######################### 4.10.2.3 303 lis a basically very unsatisfactory design because of the round trip. As this is a new spec, suggest defined 20X code meaning like a 303 but containing the representation of the thing 303d to. This has been found to a problem in LD. LDP can avoid it now. Benefit: First page back to user in one less round trip. ######################### 4.10.2.4.3 This design puts the type and next links in the data. I prefer I think using HTTP headers here as elsewhere. Page control stuff is very meta, messy to have it in with actual data. Not a problem for containers, but for normal LDPRs IMHO. [Working Group decision] Given the time constraints under which the WG is it is deemed unpractical to depend on defining a new response code as suggested. However, based on input from several HTTP experts the WG decided to return the first page with 200 response code on initial GET which prevents the additional roundtrip you objected to. See http://www.w3.org/2013/meeting/ldp/2013-11-04#resolution_2 Move Paging information out of the RDF content into HTTP headers. See http://www.w3.org/2013/meeting/ldp/2013-09-30#resolution_2 [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2837 Tim Berners-Lee (archived comment) [Comment] 4.11.1 "LDP does not provide clients with any way to detect whether or not the server is capable of inlining (all its resources or any specific resource), nor does it provide clients with any way to influence which (if any) resources are inlined in any given response." This implies cleints must all be able to handle inlining and recover from it if they didn't really want it. Need to define a protocol here properly or abandon the feature. (N3 or one of its weak imitations is obviously a clear choice for a inlined data, as it allows you to preserve the provenance, and basically explain which triples are from which resource. I understand this would frighten people at this stage.) [Working Group decision] Drop inlining from the spec, put it on the wish list for LDPnext See http://www.w3.org/2013/meeting/ldp/2013-09-12#resolution_2 [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2813 Ashok Malhotra (archived comment) [Comment] The spec says nothing about access control. Give that we are discussing read-write capabilities should we add some words like “To work with LDPRs clients must be authorized by the server and must have appropriate access control permissions”? [Working Group decision] Dispose of LC-2813 by adding a non-normative section on security setting the expectation right, pointing out that this isn't covered in LDP See http://www.w3.org/2013/meeting/ldp/2013-09-12#resolution_5 See new Security Considerations section https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#security [Commentor reply]

Output: yes

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2814 Ashok Malhotra (archived comment) [Comment] The spec also says nothing about authentication. Should we specify some minimum level of authentication, for example: LDP servers that require authentication SHOULD consider supporting basic authentication as specified in *[**RFC2617]*** over HTTPS for the highest level of interoperability with generic clients. They MAY also support other authentication methods. [Working Group decision] Same as LC-2813. [Commentor reply]

Output: yes

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2815 Ashok Malhotra (archived comment) [Comment] We discussed that LDPCs are a subclass of LDPRs and so containers can be members of other containers. Do we say that somewhere? I could not find such a statment. Perhaps we need to add it. Also, of a container contains other containers, how would ordering work? [Working Group decision] Added some informative content to 5.1.2 Ordering section. [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2816 Ashok Malhotra (archived comment) [Comment] Some comments on section 5.1.4 Ordering 1. Why is this section non-normative, given that it defines ldp:containerSortCriteria and ldp:containerSortPredicate [Working Group decision] Erroneous comment. See http://lists.w3.org/Archives/Public/public-ldp-comments/2013Aug/0005.html [Commentor reply]

Output: yes

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2838 Tim Berners-Lee (archived comment) [Comment] How does a client find the non-member-property version of a resource R? [Working Group decision] This is defined by the response header of the form: Link: rel="http://www.w3.org/ns/ldp#nonMemberResource" This is detailed in section 5.9.1 http://www.w3.org/TR/2013/WD-ldp-20130730/#ldpc-5_9_1 [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2839 Tim Berners-Lee (archived comment) [Comment] 4.10.1 "The triples in the representation of the each page are typically a subset of the triples in the resource - same subject, predicate and object." Same triples then? eh? I prefer the word "inspect" for the way "introspect" is used in the document. "Introspection" is normally looking into oneself, not into something else. [Working Group decision] Changed the offending text to clarify intent and use inspect rather than introspect per Tim's recommendation. [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Commentor] LC-2840 Tim Berners-Lee (archived comment) [Comment] 4.1 "burden of constraints for resource creation" - I feel that phrase needs more explanation [Working Group decision] This was discussed at the F2F5 and the WG agreed to change the confusing sentence to the following: How can the server make it easy for the client to create resources? See http://www.w3.org/2013/meeting/ldp/2014-04-15#LDP_Specification [Commentor reply]

Output: tocheck

Disposition of comments for the Linked Data Platform (LDP) Working Group - Comments Tracker


Input: [Operation] encrypt [Parameters] AesCbcParams [Result]

Output: ArrayBuffer


Input: [Operation] decrypt [Parameters] AesCbcParams [Result]

Output: ArrayBuffer


Input: [Operation] generateKey [Parameters] AesKeyGenParams [Result]

Output: CryptoKey


Input: [Operation] importKey [Parameters] None [Result]

Output: CryptoKey


Input: [Operation] exportKey [Parameters] None [Result]

Output: object


Input: [Operation] get key length [Parameters] AesDerivedKeyParams [Result]

Output: Integer


Input: [Event name] loadstart [Interface] ProgressEvent [PROGRESS] [Preconditions] networkState equals LOADING [Dispatched when...]

Output: The user agent begins fetching the media data, synchronously during the load() method call.


Input: [Event name] progress [Interface] ProgressEvent [PROGRESS] [Preconditions] networkState is more than EMPTY and less than LOADED [Dispatched when...]

Output: The user agent is fetching media data.


Input: [Event name] loadedmetadata [Interface] Event [Preconditions] networkState equals LOADED_METADATA [Dispatched when...]

Output: The user agent is fetching media data, and the media resource's metadata has just been received.


Input: [Event name] loadedfirstframe [Interface] Event [Preconditions] networkState equals LOADED_FIRST_FRAME [Dispatched when...]

Output: The user agent is fetching media data, and the media resource's first frame has just been received.


Input: [Event name] load [Interface] ProgressEvent [PROGRESS] [Preconditions] networkState equals LOADED [Dispatched when...]

Output: The user agent finishes downloading the entire media resource.


Input: [Event name] abort [Interface] ProgressEvent [PROGRESS] [Preconditions] error is an object with the code MEDIA_ERR_ABORTED. networkState equals either EMPTY or LOADED, depending on when the download was aborted. [Dispatched when...]

Output: The user agent stops fetching the media data before it is completely downloaded. This can be fired synchronously during the load() method call.


Input: [Event name] error [Interface] ProgressEvent [PROGRESS] [Preconditions] error is an object with the code MEDIA_ERR_NETWORK_ERROR or higher. networkState equals either EMPTY or LOADED, depending on when the download was aborted. [Dispatched when...]

Output: An error occurs while fetching the media data.


Input: [Event name] emptied [Interface] Event [Preconditions] networkState is EMPTY; all the DOM attributes are in their initial states. [Dispatched when...]

Output: A media element whose networkState was previously not in the EMPTY state has just switched to that state (either because of a fatal error during load that's about to be reported, or because the load() method was reinvoked, in which case it is fired synchronously during the load() method call).


Input: [Event name] stalled [Interface] ProgressEvent [Dispatched when...]

Output: The user agent is trying to fetch media data, but data is unexpectedly not forthcoming.


Input: [Event name] play [Interface] Event [Preconditions] paused is newly false. [Dispatched when...]

Output: Playback has begun. Fired after the play method has returned.


Input: [Event name] pause [Interface] Event [Preconditions] paused is newly true. [Dispatched when...]

Output: Playback has been paused. Fired after the pause method has returned.


Input: [Event name] waiting [Interface] Event [Preconditions] readyState is either DATA_UNAVAILABLE or CAN_SHOW_CURRENT_FRAME, and paused is false. Either seeking is true, or the current playback position is not contained in any of the ranges in buffered. It is possible for playback to stop for two other reasons without paused being false, but those two reasons do not fire this event: maybe playback ended, or playback stopped due to errors. [Dispatched when...]

Output: Playback has stopped because the next frame is not available, but the user agent expects that frame to become available in due course.


Input: [Event name] seeking [Interface] Event [Dispatched when...]

Output: The seeking DOM attribute changed to true and the seek operation is taking long enough that the user agent has time to fire the event.


Input: [Event name] seeked [Interface] Event [Dispatched when...]

Output: The seeking DOM attribute changed to false.


Input: [Event name] timeupdate [Interface] Event [Dispatched when...]

Output: The current playback position changed in an interesting way, for example discontinuously.


Input: [Event name] ended [Interface] Event [Preconditions] currentTime equals the effective end; ended is true. [Dispatched when...]

Output: Playback has stopped because the end of the media resource was reached.


Input: [Event name] dataunavailable [Interface] Event [Preconditions] The readyState attribute is newly equal to DATA_UNAVAILABLE. [Dispatched when...]

Output: The user agent cannot render the data at the current playback position because data for the current frame is not immediately available.


Input: [Event name] canshowcurrentframe [Interface] Event [Preconditions] The readyState attribute is newly equal to CAN_SHOW_CURRENT_FRAME. [Dispatched when...]

Output: The user agent cannot render the data after the current playback position because data for the next frame is not immediately available.