Re: [whatwg] DOM3 Load and Save for simple parsing/serialization?
On Mon, May 18, 2009 at 5:45 AM, Brett Zamir bret...@yahoo.com wrote: Has any thought been given to standardizing on at least a part of DOM Level 3 Load and Save in HTML5? The Load and Save APIs in DOM 3 are much too complicated IMHO so I'd like to see something simpler standardized. We've had parsing and serializing APIs in Firefox for ages. Would be very exited to see someone put in effort to get their API cleaned up and standardized. https://developer.mozilla.org/En/DOMParser https://developer.mozilla.org/En/XMLSerializer / Jonas
Re: [whatwg] Writing authoring tools and validators for custom microdata vocabularies
On May 20, 2009, at 04:36, Ian Hickson wrote: REQUIREMENTS: * There should be a definitive location for vocabularies. If this means that vocabulary schemas should live in a predestined URI subspace, I'm inclined to disagree with this requirement, because 1) for non-predefined vocabularies it would leave vocabulary definition as decentralized but would make schemas centralized, which doesn't make sense 2) for predefined vocabularies it would create a single point of failure by elevating a given dereferencable URI to a special status. * It should be possible for vocabularies to describe other vocabularies. I disagree with this requirement. Being able to define a schema language in microdata is sufficiently different from other microdata use cases that addressing this requirement could have adverse complicating effects on other use cases. Furthermore, it is completely unclear why schemas would need to be embedded in HTML pages. * Originating vocabulary documents should be discoverable. Does this mean something like xsi:schemaLocation? I thought that the RELAX NG community had debunked this as an anti-pattern for all other cases except for use cases analogous to the Emacs modeline (i.e. giving a generic XML editor a path to a *local* schema file in order to choose autocompletion rules on a per-document basis). See http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html * Machine-readable vocabulary information shouldn't be on a separate page than the human-readable explanation. Why is this a requirement? It seems like a radical departure from the practice of having DTD / XSD / RELAX NG schemas in addition to spec prose in HTML or PDF. * There must not be restrictions on the possible ways vocabularies can be expressed (e.g. the way DTDs restricted possible grammars in SGML). This seems to preclude any generic schema language as the One True schema language. For other vocabularies, I recommend using RDFS and OWL, and having the tools support microdata as a serialisation of RDF. I'm inclined to think this recommendation may not be the best one. It seems that RDFS or OWL are obviously applicable to the result of microdata to RDF conversion. However, RDFS and OWL are designed for the RDF model, which is more general than the microdata model. Since the microdata model is an array of trees (which may be considered one big tree with the root being of a different type than the other nodes), it would make sense--on the high level--to apply the same techniques one would apply with XML trees: tree automata (like RELAX NG), assertions on trees (like Schematron) and custom code operating on trees. While it would be possible to make new schema languages for microdata applying the ideas from RELAX NG and Schematron, it would be easier to use off-the-shelf RELAX NG and Schematron tools and to map microdata to an XML infoset for validation. However, in order to usefully apply RELAX NG or Schematron to a microdata-base infoset, the infoset conversion should turn property names into element names. Since XML places arbitrary limitations on element names (and element content), this mapping would have exactly the same complications as mapping microdata to RDF/XML. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Link rot is not dangerous
On 20 May 2009, at 05:23, Tab Atkins Jr. wrote: Specifically, people can use a search engine to find information about foaf. I know that typing foaf into my browser's address bar and clicking on the first likely link is *way* faster than digging into a document with a foaf namespace declared, finding the url, and copy/pasting that into the location bar. FOAF is a very famous vocabulary, so this happens to work quite well for FOAF. Consider Dublin Core though. Typing dc into Google brings up results for DC Comics, DC Shoes, Washington DC and a file sharing application called Direct Connect, all ahead of Dublin Core, which is the nineth result. Even if I spot that result, clicking through takes me to the Dublin Core Metadata Initiative's homepage, which is mostly full of conference and event information - not the definitions I'm looking for. On the other hand, typing http://purl.org/dc/terms/issued into my browser's address bar gives me an RDFS definition of the term immediately. Your suggestion also makes the assumption that there is a single correct answer that Google/Yahoo/whatever could give to such a query - that any given string used as a prefix will only ever be legitimately bound to one vocabulary. That is simply not the case: dc for example is most often used with Dublin Core Elements 1.1, but still occasionally seen as a prefix for the older 1.0 version, and increasingly being used with the new Dublin Core Terms collection. While Elements 1.0 and 1.1 are largely compatible (the latter introduces two extra terms IIRC), Dublin Core Terms has significant differences. bio is another string commonly bound to different vocabularies - both the biographical vocab often used in conjunction with FOAF, plus various life-science-related vocabularies. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: [whatwg] DOM3 Load and Save for simple parsing/serialization?
On May 19, 2009, at 11:49 PM, Jonas Sicking wrote: On Mon, May 18, 2009 at 5:45 AM, Brett Zamir bret...@yahoo.com wrote: Has any thought been given to standardizing on at least a part of DOM Level 3 Load and Save in HTML5? The Load and Save APIs in DOM 3 are much too complicated IMHO so I'd like to see something simpler standardized. We've had parsing and serializing APIs in Firefox for ages. Would be very exited to see someone put in effort to get their API cleaned up and standardized. https://developer.mozilla.org/En/DOMParser https://developer.mozilla.org/En/XMLSerializer WebKit actually implements most of these. I think it would make sense to publish these as a WebApps spec. But these classes don't do any loading or saving, just parsing and serializing. Document.load would be the simplified load/save method that it would make sense to standardize IMO, since Firefox has it and it is needed for Web compatibility. I am concerned though that Document.load() allows for synchronous network loads. Regards, Maciej
Re: [whatwg] DOM3 Load and Save for simple parsing/serialization?
On Wed, May 20, 2009 at 12:49 AM, Maciej Stachowiak m...@apple.com wrote: On May 19, 2009, at 11:49 PM, Jonas Sicking wrote: On Mon, May 18, 2009 at 5:45 AM, Brett Zamir bret...@yahoo.com wrote: Has any thought been given to standardizing on at least a part of DOM Level 3 Load and Save in HTML5? The Load and Save APIs in DOM 3 are much too complicated IMHO so I'd like to see something simpler standardized. We've had parsing and serializing APIs in Firefox for ages. Would be very exited to see someone put in effort to get their API cleaned up and standardized. https://developer.mozilla.org/En/DOMParser https://developer.mozilla.org/En/XMLSerializer WebKit actually implements most of these. I think it would make sense to publish these as a WebApps spec. But these classes don't do any loading or saving, just parsing and serializing. Doesn't XMLHttpRequest do all the load/save that is needed? I don't know how would could standardize save beyond that without relying on something like WebDAV. Document.load would be the simplified load/save method that it would make sense to standardize IMO, since Firefox has it and it is needed for Web compatibility. I am concerned though that Document.load() allows for synchronous network loads. I'm certainly no fan of Document.load() and wish it would go away. In fact we have decided not to add any additional features such as CORS or progress event support in order to discourage its use and move people to XHR instead. / Jonas
Re: [whatwg] DOM3 Load and Save for simple parsing/serialization?
Jonas Sicking wrote: On Wed, May 20, 2009 at 12:49 AM, Maciej Stachowiakm...@apple.com wrote: On May 19, 2009, at 11:49 PM, Jonas Sicking wrote: On Mon, May 18, 2009 at 5:45 AM, Brett Zamirbret...@yahoo.com wrote: Has any thought been given to standardizing on at least a part of DOM Level 3 Load and Save in HTML5? The Load and Save APIs in DOM 3 are much too complicated IMHO so I'd like to see something simpler standardized. We've had parsing and serializing APIs in Firefox for ages. Would be very exited to see someone put in effort to get their API cleaned up and standardized. https://developer.mozilla.org/En/DOMParser https://developer.mozilla.org/En/XMLSerializer WebKit actually implements most of these. I think it would make sense to publish these as a WebApps spec. But these classes don't do any loading or saving, just parsing and serializing. Doesn't XMLHttpRequest do all the load/save that is needed? I don't know how would could standardize save beyond that without relying on something like WebDAV. Document.load would be the simplified load/save method that it would make sense to standardize IMO, since Firefox has it and it is needed for Web compatibility. I am concerned though that Document.load() allows for synchronous network loads. I'm certainly no fan of Document.load() and wish it would go away. In fact we have decided not to add any additional features such as CORS or progress event support in order to discourage its use and move people to XHR instead. / Jonas Does Ajax at least have theoretical support for loading entities from an external DTD, as I presume a DOM method must? (Would be nice to hear from some others on that separate External document subset support thread too, especially to know whether all the browsers are just not inclined to ever implement this (despite all of the off-web documents that use them...)) thanks, Brett
Re: [whatwg] DOM3 Load and Save for simple parsing/serialization?
Brett Zamir wrote: Jonas Sicking wrote: On Wed, May 20, 2009 at 12:49 AM, Maciej Stachowiakm...@apple.com wrote: On May 19, 2009, at 11:49 PM, Jonas Sicking wrote: On Mon, May 18, 2009 at 5:45 AM, Brett Zamirbret...@yahoo.com wrote: Has any thought been given to standardizing on at least a part of DOM Level 3 Load and Save in HTML5? The Load and Save APIs in DOM 3 are much too complicated IMHO so I'd like to see something simpler standardized. We've had parsing and serializing APIs in Firefox for ages. Would be very exited to see someone put in effort to get their API cleaned up and standardized. https://developer.mozilla.org/En/DOMParser https://developer.mozilla.org/En/XMLSerializer WebKit actually implements most of these. I think it would make sense to publish these as a WebApps spec. But these classes don't do any loading or saving, just parsing and serializing. Doesn't XMLHttpRequest do all the load/save that is needed? I don't know how would could standardize save beyond that without relying on something like WebDAV. Document.load would be the simplified load/save method that it would make sense to standardize IMO, since Firefox has it and it is needed for Web compatibility. I am concerned though that Document.load() allows for synchronous network loads. I'm certainly no fan of Document.load() and wish it would go away. In fact we have decided not to add any additional features such as CORS or progress event support in order to discourage its use and move people to XHR instead. / Jonas Does Ajax at least have theoretical support for loading entities from an external DTD, as I presume a DOM method must? (Would be nice to hear from some others on that separate External document subset support thread too, especially to know whether all the browsers are just not inclined to ever implement this (despite all of the off-web documents that use them...)) Sorry, guess I can answer the first part of my question, yes it is theoretically possible... Per http://www.w3.org/TR/XMLHttpRequest/#responsexml , Return the XML response entity body. - Parse the response entity body into a document tree following the rules from the XML specifications. But I'm still holding out hope that the ability to at least parse an external DTD for entities alone would be considered... Brett
Re: [whatwg] DOM3 Load and Save for simple parsing/serialization?
Brett Zamir wrote: Brett Zamir wrote: Jonas Sicking wrote: On Wed, May 20, 2009 at 12:49 AM, Maciej Stachowiakm...@apple.com wrote: On May 19, 2009, at 11:49 PM, Jonas Sicking wrote: On Mon, May 18, 2009 at 5:45 AM, Brett Zamirbret...@yahoo.com wrote: Has any thought been given to standardizing on at least a part of DOM Level 3 Load and Save in HTML5? The Load and Save APIs in DOM 3 are much too complicated IMHO so I'd like to see something simpler standardized. We've had parsing and serializing APIs in Firefox for ages. Would be very exited to see someone put in effort to get their API cleaned up and standardized. https://developer.mozilla.org/En/DOMParser https://developer.mozilla.org/En/XMLSerializer WebKit actually implements most of these. I think it would make sense to publish these as a WebApps spec. But these classes don't do any loading or saving, just parsing and serializing. Doesn't XMLHttpRequest do all the load/save that is needed? I don't know how would could standardize save beyond that without relying on something like WebDAV. Document.load would be the simplified load/save method that it would make sense to standardize IMO, since Firefox has it and it is needed for Web compatibility. I am concerned though that Document.load() allows for synchronous network loads. I'm certainly no fan of Document.load() and wish it would go away. In fact we have decided not to add any additional features such as CORS or progress event support in order to discourage its use and move people to XHR instead. / Jonas Does Ajax at least have theoretical support for loading entities from an external DTD, as I presume a DOM method must? (Would be nice to hear from some others on that separate External document subset support thread too, especially to know whether all the browsers are just not inclined to ever implement this (despite all of the off-web documents that use them...)) Sorry, guess I can answer the first part of my question, yes it is theoretically possible... Per http://www.w3.org/TR/XMLHttpRequest/#responsexml , Return the XML response entity body. - Parse the response entity body into a document tree following the rules from the XML specifications. But I'm still holding out hope that the ability to at least parse an external DTD for entities alone would be considered... Argh... Didn't read far enough... resources referenced will not be loaded... So now I'm having to hold out hope on both counts... Brett
Re: [whatwg] Cross-domain databases; was: File package protocol and manifest support?
Hi, On Tuesday, May 19, 2009, Drew Wilson atwil...@google.com wrote: One alternate approach to providing this support would be via shared, cross-domain workers (yes, workers are my hammer and now everything looks like a nail :) - this seems like one of the canonical uses of cross-domain workers, in fact. For what it's worth, this was my immediate thought as well upon reading the idea. The database is insufficiently fast on some platforms to server as an IPC mechanism and there are practical limitations with having too many contending transactions so my instinct would be to build large integrated web apps with a shared worker routing data between components. Rob. This would be potentially even more secure than a simple shared database, as it would allow the application to programmatically control access from other domains, synchronize updates, etc while allowing better controls over access (read-only, write via specific exposed write APIs, etc). -atw On Tue, May 19, 2009 at 5:26 PM, Brett Zamir bret...@yahoo.com wrote: I would like to suggest an incremental though I believe significant enhancement to Offline applications/SQLite. That is, the ability to share a complete database among offline applications according to the URL from which it was made available. It could be designated by the origin site as a read-only database, or also potentially with shared write access, shareable with specific domains or all domains, and perhaps also with a mechanism to indicate the license of its contents. Perhaps the manifest file could include such information. Actually, there might even be a shared space for databases directly downloaded by the user (or by an application) which would allow all applications access, no doubt requiring UA permission. Ideally the origin site could also have control over providing an update to the database (not necessarily through manually performing UPDATE commands, but potentially by simply providing a new database at the previous location which was checked periodically for a new modification date). I don't know whether it would ideal to tie this in to the caching API (perhaps deleting the database reference could also cause it to be re-downloaded and also force the database to be re-created). Perhaps the cache API could also be optionally shared with other domains as well, allowing them to ensure their application was working with the latest data. I believe custom protocols will also play into this well, as there could be a number of uses for operating on the same data set while linking to it in a way which is application-independent. (Thanks to Kristof Zelechovski for helping me distill the essence of the idea a bit more succinctly and more in line with HTML 5's progress to date.) Brett -- Rob Kroeger rjkro...@liqui.org http://www.liqui.org
Re: [whatwg] Writing authoring tools and validators for custom microdata vocabularies
Ian -- There's an authoring and reasoning tool that you may like to evaluate for your purposes. A possible advantage of the tool for your tasks is that it explains its answers, step by step, in hypertexted English. The vocabulary for writing rules in executable English is open, but the tool can reason about controlled vocabularies, inheritance, and so on. It covers some examples that are not do-able in OWL. The tool is online at the site below. Apologies if you have seen this before, and thanks for comments. -- Adrian Internet Business Logic A Wiki and SOA Endpoint for Executable Open Vocabulary English over SQL and RDF Online at www.reengineeringllc.comShared use is free Adrian Walker Reengineering On Tue, May 19, 2009 at 9:36 PM, Ian Hickson i...@hixie.ch wrote: One of the use cases I collected from the e-mails sent in over the past few months was the following: USE CASE: It should be possible to write generalized validators and authoring tools for the annotations described in the previous use case. SCENARIOS: * Mary would like to write a generalized software tool to help page authors express micro-data. One of the features that she would like to include is one that displays authoring information, such as vocabulary term description, type information, range information, and other vocabulary term attributes in-line so that authors have a better understanding of the vocabularies that they're using. * John would like to ensure that his indexing software only stores type-valid data. Part of the mechanism that he uses to check the incoming micro-data stream is type information that is embedded in the vocabularies that he uses. * Steve, would like to provide warnings to the authors that use his vocabulary that certain vocabulary terms are experimental and may never become stable. REQUIREMENTS: * There should be a definitive location for vocabularies. * It should be possible for vocabularies to describe other vocabularies. * Originating vocabulary documents should be discoverable. * Machine-readable vocabulary information shouldn't be on a separate page than the human-readable explanation. * There must not be restrictions on the possible ways vocabularies can be expressed (e.g. the way DTDs restricted possible grammars in SGML). * Parsing rules should be unambiguous. * Should not require changes to HTML5 parsing rules. I couldn't find a good solution to this problem. The obvious solution is to use a schema language, such as RDFS or OWL. Indeed, that's probably the only solution that I can recommend. However, as we discovered with HTML5, schema languages aren't expressive enough. I wouldn't be surprised to find that no existing schema could accurately describe the complete set of requirements that apply to the vCard, vEvent, and BibTeX vocabularies (though I haven't checked if this is the case). For any widely used vocabulary, I think the best solution will be hard-coded constraints and context-sensitive help systems, as we have for HTML5 validators and HTML editors. For other vocabularies, I recommend using RDFS and OWL, and having the tools support microdata as a serialisation of RDF. Microdata itself could probably be used to express the constraints, though possibly not directly in RDFS and OWL if these use features that microdata doesn't currently expose (like typed properties). Regarding some of the requirements, I actually disagree that they are desireable. For example, having a definitive location for vocabularies has been shown to be a bad idea for scalability, with the W3C experiencing huge download volume for certain schemas. Similarly, I don't think that the turtles all the way down approach of describing vocabularies using the same syntax as the definition is about (self-hosted schemas) is necessary or, frankly, particularly useful to the end-user (though it may have nice theoretical properties). In conclusion: I recommend using an existing RDF-based schema language in conjunction with the mapping of microdata to RDF. Implementation experience with how this actually works in practice in end-user schenarios would be very useful in determining if something more is needed here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Link rot is not dangerous
Kristof Zelechovski wrote: Following the URL to discover the semantic of properties is not only useful but can also be necessary for CURIE, e.g. when the author uses a paradoxical prefix just for the fun of it. A language without CURIE would not expose the users to this necessity. If you have to CURIE, you have to FYN. Just my POV, Chris CURIEs vs URI is only a syntactical difference; you don't need to FYN as long as you are happy with a URI as identifier. BR, Julian
Re: [whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
Note: I wrote this yesterday. My internet connection wasn't working as desirable, but GMail told me it had been sent and I believed it. Now I have just noticed that it hadn't; and at least one person has been confused by the changes in the document. Sorry for this issue, and hope this time GMail does send it. What follows is the message as it should have been sent yesterday: Update: I have just put up a new version of the CRDF document. The main changes are: Section 0. Rationale: several corrections on the claimed limitations of RDFa, which have been shown to be just limitations of my knowledge about RDFa. Section 2. Syntax: the syntax is now more formally defined (although it still refers to CSS3's Syntax, Values, and Namespace modules for some stuff). The content model for property values is now fully defined: resource and reversed support has been added, and explicit typing capabilities are now more prominent in the document. For subject definitions, the none keyword has been redefined; blank() now handles what none previously did, and a syntax has been added to mimic EASE's nearest-ancestor construct. Finally, a subsection has been added describing how to handle escenarios where a tool might have to extract an XML literal from source in a non-XML language. Section 3. The host language: expanded 3.3 (embedding inline CRDF) to allow multiple brace-delimited blocks within the attribute value, to enable stating properties for different subjects while reusing the same element. Section 4. The first examples don't make sense anymore after the changes in section 0. They have been removed, waiting for further feedback on that section before redoing them. I'd like to reiterate what I said in the opening message: if someone can suggest of a better place to discuss this document, please let me know.
[whatwg] on bibtex-in-html5
Re: the recent microdata work and the subsequent effort to include BibTeX in the spec, I summarized my argument against this on my blog: http://community.muohio.edu/blogs/darcusb/archives/2009/05/20/on-the-inclusion-of-bibtex-in-html5 I think it's fair to say that the Zotero project [1] agrees with my thoughts; Dan Cohen just said as much in an email, where he expressed concern both with the introduction of a new generic metadata-in-HTML spec alongside RDFa, and also the use of BibTeX in particular. Thanks to Ian for the email conversation on this, BTW, and for taking the basic use case seriously. Bruce PS - Brief background on me: am a professional scholar (a social scientist) [2], and author or co-author of some relevant work in this area: the Bibliographic Ontology [3], and the Citation Style Language (CSL) [4], both of which have been collaborations with Zotero (among others). I also had a major hand in the new RDF/RDFa-based extensible metadata support in OpenDocument 1.2. So I have quite a bit of practical experience on different sides of this: both user and developer. [1] http://zotero.org [2] http://bruce.darcus.name [3] http://bibliontology.com/ [4] http://xbiblio.sourceforge.net/csl/
Re: [whatwg] Link rot is not dangerous
On Wed, May 20, 2009 at 2:35 AM, Toby A Inkster m...@tobyinkster.co.uk wrote: On 20 May 2009, at 05:23, Tab Atkins Jr. wrote: Specifically, people can use a search engine to find information about foaf. I know that typing foaf into my browser's address bar and clicking on the first likely link is *way* faster than digging into a document with a foaf namespace declared, finding the url, and copy/pasting that into the location bar. FOAF is a very famous vocabulary, so this happens to work quite well for FOAF. Consider Dublin Core though. Typing dc into Google brings up results for DC Comics, DC Shoes, Washington DC and a file sharing application called Direct Connect, all ahead of Dublin Core, which is the nineth result. Even if I spot that result, clicking through takes me to the Dublin Core Metadata Initiative's homepage, which is mostly full of conference and event information - not the definitions I'm looking for. On the other hand, typing http://purl.org/dc/terms/issued into my browser's address bar gives me an RDFS definition of the term immediately. As Kristof said, while typing dc isn't very helpful, typing pretty much any relevant property works great. dc:title, dc:creator, whatever. It all brings up some decent results right at the top of a Google search. Your suggestion also makes the assumption that there is a single correct answer that Google/Yahoo/whatever could give to such a query - that any given string used as a prefix will only ever be legitimately bound to one vocabulary. That is simply not the case: dc for example is most often used with Dublin Core Elements 1.1, but still occasionally seen as a prefix for the older 1.0 version, and increasingly being used with the new Dublin Core Terms collection. While Elements 1.0 and 1.1 are largely compatible (the latter introduces two extra terms IIRC), Dublin Core Terms has significant differences. bio is another string commonly bound to different vocabularies - both the biographical vocab often used in conjunction with FOAF, plus various life-science-related vocabularies. And yet, given an example use of the vocabulary, I'm quite certain I can easily find the page I want describing the vocab, even when there are overlaps in prefixes such as with bio. FYN is nearly never necessary for humans. We have the intelligence to craft search queries and decide which returned result is correct. ~TJ
Re: [whatwg] Link rot is not dangerous
On 20/5/09 22:54, Tab Atkins Jr. wrote: On Wed, May 20, 2009 at 2:35 AM, Toby A Inksterm...@tobyinkster.co.uk wrote: And yet, given an example use of the vocabulary, I'm quite certain I can easily find the page I want describing the vocab, even when there are overlaps in prefixes such as with bio. FYN is nearly never necessary for humans. We have the intelligence to craft search queries and decide which returned result is correct. What happens in practice is that many of these perfectly intelligent humans ask in email or IRC questions that are clearly answered directly in the relevant documentation. You can lead humans to the documentation, but you can't make 'em read... cheers, Dan
Re: [whatwg] DOM3 Load and Save for simple parsing/serialization?
Document.load would be the simplified load/save method that it would make sense to standardize IMO, since Firefox has it and it is needed for Web compatibility. I am concerned though that Document.load() allows for synchronous network loads. I'm certainly no fan of Document.load() and wish it would go away. In fact we have decided not to add any additional features such as CORS or progress event support in order to discourage its use and move people to XHR instead. For better or for worse, enough sites seem to rely on it that we'll likely have to implement it in WebKit: https://bugs.webkit.org/show_bug.cgi?id=9063 That says to me that it should likely be standardized in some form, even if it is discouraged. Yeah, probably. It'd be nice to start deprecating it right away though (by adding a warning message any time someone is using it in the error console). However it'd probably take a while before usage has reduced to the point where we can drop support. / Jonas
[whatwg] DOMParser / XMLSerializer
Although it seems most browsers have adopted these APIs, HTML5 offers basically identical APIs in the form of document.innerHTML or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
On Wed, May 20, 2009 at 11:56 AM, Toby Inkster m...@tobyinkster.co.uk wrote:
Given that one of the objections people cite with RDFa is complexity,
I'm not sure how this resolves things. It seems twice as complicated to
me. It creates fewer new attributes, true, but number of attributes
themselves don't create much confusion.
e.g. which is a simpler syntax:
a href=http://foo.example.com/;
ping=http://tracker.example.com/;Foo/a
or:
a href=primary:url('http://foo.example.com/');
secondary:url('http://tracker.example.com/');Foo/a
I'm not sure how this example is relevant. Links do one thing and do
it visibly; they benefit from a simple, straightforward syntax and a
proliferation of attributes that have direct meaning. Any metadata
proposal, on the other hand, has attributes which acquire meaning only
through their values and the vocab being used, and there is a
necessary degree of indirection which makes things more difficult.
It would have actually been useful had the comparison been between
pseudo-CRDF and pseudo-RDFa, or better yet, actual CRDF and RDFa.
That way we have two things which can actually be compared.
Stuffing multiple discrete pieces of information makes things harder for
parsing, harder for authoring tools and harder for authors. In RDFa,
each attribute performs a simple role - e.g. @rel specifies the
relationship between two resources; @rev specifies the relationship in
the reverse direction; @content allows you to override the
human-readable text of an element. Combining these into a single
attribute would not make things simpler.
You're leaving out @about, @property, @resource, @datatype, @typeof,
and numerous implicit uses of @href or @src, along with with implicit
chaining with contained nodes. Please don't misrepresent the
simplicity of RDFa - it's a generic metadata extraction method, and is
rather complex. So is CRDF, of course, but that's not disputed.
(Also, the argument against @rev is still going strong - in the RDFa
in XHTML document, section 6.3.2.2, the foaf:img relation is misused
in @rev, causing the RDF to state that Mark is an image of the img
resource! @rev really is too confusing for standard use - just add
inverted @rel values when necessary.)
Looking at the comparison given in section 4.2, CRDF appears to suffer
from several disadvantages compared to RDFa:
1. It's pretty ugly.
We are going to have to massively disagree on this point. ^_^ I love
CSS syntax. It's small, elegant, and simple. CRDF benefits from all
of this. Inline CRDF isn't ideal, but it benefits from being
identical to standard CRDF syntax, as well as resembling inline CSS in
@style.
RDFa (and Microdata, to a lesser extent), on the other hand, look like
you invented a half-dozen versions of @style which all do something
different but all have to be used together to style your document. To
me it looks like the uneditted HTML that Microsoft products will spew
out if you let them.
So, I guess beauty is in the eye of the beholder. ^_^
2. It's more verbose - though only by eleven bytes by my reckoning, so
this isn't a major issue.
When used inline, it may be. It's not *intended* to be used inline,
though - that's just there for the occasional case when you absolutely
need to do so, just as @style is available but discouraged in favor of
external CSS.
When used as intended, as a separate CRDF file, you see immediate
savings as soon as you have two things with the same data structure.
I think I'm reasonable in assuming that most users of any metadata
solution will be doing so in medium-to-large quantities, not
individual isolated instances with unique structure. They can deploy
a single CRDF file across their entire site, automatically allowing
metadata extraction from their content with no further effort. At
worst, they have to add a few classes, perhaps some spans.
3. It divorces the CURIE prefix definitions from the use of CURIEs in
the markup. This makes it more vulnerable to copy-paste problems. (As I
understand link rel=metadata in the proposal, CURIE prefix
definitions can even be separated out into an external file. This
obscures them greatly and will certainly be a cause of copy-paste
issues!)
If you're using inline CRDF, then yeah, the prefix definitions may be
far from the content. The prefixes are defined globally for the
document, and may appear anywhere. In practice, inline CRDF should be
rare, and the prefixes should appear at the top of the .crdf file
where they can be easily seen.
Apart from the fact that *sometimes* RDFa involves a bit of repetition,
I don't see what problems this proposal is actually supposed to solve.
You're being disingenuous. RDFa *always* requires *large* amounts of
verbose repetition whenever you're indicating the same metadata
structure multiple times. I expect that this type of use will be by
far the most common if metadata embedding takes off as hoped for.
One-shot uses like on bios will
Re: [whatwg] Link rot is not dangerous
On Wed, May 20, 2009 at 4:02 PM, Dan Brickley dan...@danbri.org wrote: On 20/5/09 22:54, Tab Atkins Jr. wrote: On Wed, May 20, 2009 at 2:35 AM, Toby A Inksterm...@tobyinkster.co.uk wrote: And yet, given an example use of the vocabulary, I'm quite certain I can easily find the page I want describing the vocab, even when there are overlaps in prefixes such as with bio. FYN is nearly never necessary for humans. We have the intelligence to craft search queries and decide which returned result is correct. What happens in practice is that many of these perfectly intelligent humans ask in email or IRC questions that are clearly answered directly in the relevant documentation. You can lead humans to the documentation, but you can't make 'em read... This is an unfortunate reality, and one which cannot be cured simply be embedding a url reasonably close to the location. I humbly suggest using www.lmgtfy.com to chastise the lazy bums while remaining helpful. ^_^ ~TJ
Re: [whatwg] DOMParser / XMLSerializer
On Wed, 20 May 2009 23:20:34 +0200, Anne van Kesteren ann...@opera.com wrote: Although it seems most browsers have adopted these APIs, HTML5 offers basically identical APIs in the form of document.innerHTML or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? XMLSerializer must generate well formed xml (all tags closed, no attributes without values, case preserved, etc) and it accepts a full document, so you get a serialized output with doctype, processing instructions, comments which are not descendants of the root, and the root itself. DOMParser parses xml into a full document so if I have a doctype subset, those will be recognized and replaced on the document. That does not happen with innerHTML. If the input source has processing instructions, these will be preserved also in the result document. These are duplicates of the functionality provided on DOM 3 LS, and developer prefer these because their APIs are simpler and more convenient.
Re: [whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
On 20 May 2009, at 23:10, Tab Atkins Jr. wrote: Stuffing multiple discrete pieces of information makes things harder for parsing, harder for authoring tools and harder for authors. In RDFa, each attribute performs a simple role - e.g. @rel specifies the relationship between two resources; @rev specifies the relationship in the reverse direction; @content allows you to override the human-readable text of an element. Combining these into a single attribute would not make things simpler. You're leaving out @about, @property, @resource, @datatype, @typeof, All of which have similarly simple usages: @about = sets the URI for the thing we're talking about @property = specifies what property the element's text represents @resource = provides a link which is the object of @rel / subject of @rev @datatype = specifies the type of data for an element with @property @typeof = specifies the type for a new resource and numerous implicit uses of @href or @src, @href == @resource (but at a lower priority, so latter can override) @src == @about (but at a lower priority, so latter can override) along with with implicit chaining with contained nodes. Please don't misrepresent the simplicity of RDFa - it's a generic metadata extraction method, and is rather complex. So is CRDF, of course, but that's not disputed. Each attribute is rather simple and has a simple syntax. Chaining them together becomes more complicated, I don't dispute that - but chaining together anything tends to increase complexity significantly (consider the implications of nested elements on onclick handling in Javascript - the result is event bubbling, which is hardly an easy concept for newcomers to Javascript). But as each individual attribute is simple, and we can get some small gains without complex chaining, then basic uses of RDFa become pretty easy. e.g. img alt=Crazy Foo! src=foo.jpeg rel=license resource=http://example.com/license.html; Something that anyone can do to easily. Becoming familiar with simple cases will help them get to grips with how the attributes work, so they're more familiar if they feel the need to mark up more complex data. (Also, the argument against @rev is still going strong - in the RDFa in XHTML document, section 6.3.2.2, the foaf:img relation is misused in @rev, causing the RDF to state that Mark is an image of the img resource! @rev really is too confusing for standard use - just add inverted @rel values when necessary.) Both usages of foaf:img in the RDFa in XHTML document seem to be correct. I think you may be thinking of Mark's draft RDFa tutorial. He explained on the RDFa task force that this was due to his misunderstanding foaf:img rather than misunderstanding @rel. Indeed, FOAF has three different terms (img, depiction, depicts) for connecting an image to the thing depicted in the image, so it's not hard to get them mixed up. This is precisely why @rev is needed - to prevent having to define separate depicts/depiction, maker/made, primaryTopic/isPrimaryTopicOf terms. Having just one term to describe the relationship, and reversing the direction by moving it from @rel to @rev, makes vocabularies smaller and simpler. We are going to have to massively disagree on this point. ^_^ I love CSS syntax. So do I, but CRDF as defined is no more like CSS in terms of syntax than C or Perl are - they share the curly braces and semicolons, but not much else. It is rarely, if ever, necessary to set multiple img elements to the same @src or @alt. I'm thinking of things like a table which has a check-mark column with a green tick image repeated all the way down, or a traffic-light indicator column with red, green and perhaps amber images indicating different statuses. I quite often see such things in web applications. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: [whatwg] DOMParser / XMLSerializer
On Wed, May 20, 2009 at 2:20 PM, Anne van Kesteren ann...@opera.com wrote: Although it seems most browsers have adopted these APIs, HTML5 offers basically identical APIs in the form of document.innerHTML or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? Mostly I think these APIs came about before innerHTML was supported in XML content. DOMParser is also somewhat more convenient if you want a full document back. And XMLSerializer is more convenient if you want an XML serialization of text/html content. / Jonas
Re: [whatwg] DOMParser / XMLSerializer
Anne van Kesteren wrote: or is there something that DOMParser / XMLSerializer can do that document.innerHTML cannot? Ignoring the non-web-facing functionality (like parsing from and serializing to streams), and speaking only of Gecko's implementations, basically the following: 1) DOMParser can parse as a given content type (in theory XML vs HTML; I assume that if document.innerHTML doesn't do that yet it could be changed to do so). 2) DOMParser can parse from a byte array instead of a string; this makes it a little easier to work with XML in encodings other than UTF-8 or UTF-16. 2) XMLSerializer can serialize a subtree rooted at a given node without removing the node from its current location in the DOM. -Boris
[whatwg] Frame advance feature for a paused VIDEO
I dont see a way to do frame advance feature for a paused VIDEO. Is there a way to achieve that ? As well as frame backward also. Thanks Biju
