Request to publish HTML+RDFa (draft 3) as FPWD

[Manu Sporny]

The 3rd draft of the HTML+RDFa specification has been released and is
available here:

http://html5.digitalbazaar.com/specs/rdfa.html

The diff-marked version can be found here:

http://html5.digitalbazaar.com/specs/rdfa-diff-20090906-20090915.html

Changes in this version of the spec include:

* Lots of xmlns: fixes and spec language changes around xmlns:.
* Explicit references from HTML+RDFa sections to pertinent sections of
  XHTML+RDFa spec.
* Explicit language ensuring that RDFa attributes, attribute values,
  and CURIEs are conforming in HTML5 and XHTML5.
* Normative pointers to xmlns:-prefixed attribute processing that
  should be used to create URI mappings in non-XML mode documents.
* Added editorial warnings about potential changes in xmlns: as
  the HTML5 document moves toward Last Call and the distributed
  extensibility issue is addressed.

There are now 2 remaining issues, 6 deferred issues (that should be
addressed via a separate document, wiki, process), and 30 addressed
issues. Details on the status/resolution of each issue can be found here:

http://rdfa.info/wiki/html5-rdfa-wd-issues

There have been no issues that have been added to the wiki by reviewers
or that have been re-opened by reviewers since the last draft was
published. Discussion related to the second draft didn't produce any
technical issues, but that doesn't mean there aren't any. If there are
any new technical issues, they must and will be dealt with during the
Working Draft phase.

I feel confident that the remaining 2 issues can be addressed and that
the document is ready for FPWD.

Sam, Paul, Maciej, this is a request to publish HTML+RDFa as a FPWD.
Please let me know if there is any other W3C process that is required
before the document can be published as a FPWD.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Pirate Bay and Building an Equitable Culture
http://blog.digitalbazaar.com/2009/08/30/equitable-culture/

[Henri Sivonen]

On Sep 16, 2009, at 07:36, Manu Sporny wrote:

> The 3rd draft of the HTML+RDFa specification has been released and is
> available here:
>
> http://html5.digitalbazaar.com/specs/rdfa.html
>
> The diff-marked version can be found here:
>
> http://html5.digitalbazaar.com/specs/rdfa-diff-20090906-20090915.html

Section 2 is marked as normative although its content is devoid of  
normative statements.

In section 4.1, the first and second sentence seem potentially  
contradictory. It should instead say that the node of the language is  
determined according to the HTML5 rules and the result is then used in  
the processing model in the place where RDFa in XHTML says xml:lang is  
used.

> There are now 2 remaining issues, 6 deferred issues (that should be
> addressed via a separate document, wiki, process), and 30 addressed
> issues. Details on the status/resolution of each issue can be found  
> here:
>
> http://rdfa.info/wiki/html5-rdfa-wd-issues


I observe that four out of the six deferred issues depend on the two  
issues you left open. (I disagree with the characterization of the  
deferred issues as "implementation details".)

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

[Julian Reschke]

Manu Sporny wrote:

> The 3rd draft of the HTML+RDFa specification has been released and is
> available here:
>
> http://html5.digitalbazaar.com/specs/rdfa.html
>
> The diff-marked version can be found here:
>
> http://html5.digitalbazaar.com/specs/rdfa-diff-20090906-20090915.html
>
> Changes in this version of the spec include:
> ...

Very interesting; I'd like to see this published as FPWD.

Here are a few comment with respect to head/@profile and the "profile"
link relation:

- in the description of head/@profile, the format of a
whitespace-separated list of URIs should be allowed; thus, an RDFa
processor should not rely on the defined URI to be the single value.

- the current definition of the "profile" link relation makes it sound
as if it can be used exclusively with RDFa; I thought it's supposed to
be a generic replacement for head/@profile?

Looking at these two comments it appears that head/@profile and
link/@rel=profile really should be specified separately from RDFa...
(this is in fact an open HTML5 issue)

BR, Julian

[Henri Sivonen]

On Sep 16, 2009, at 10:33, Henri Sivonen wrote:

> the node of the language


Oops. The language of the node.

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

[Philip Taylor-5]

Manu Sporny wrote:
> The 3rd draft of the HTML+RDFa specification has been released and is
> available here:
>
> http://html5.digitalbazaar.com/specs/rdfa.html

I found a few things to comment on while reading through this. (I'm
mostly ignoring any high-level issues about the design of the language,
and just looking at how it's being specified.)

First, the more substantive issues:

"a tree-based model" -- is that tree-based model defined anywhere? (What
data types does it consist of? e.g. is an attribute just a name string
plus a value string, or is it a namespace URI plus a local name plus a
value string? Does an element just have a list of attributes, or does it
also have a separate list of namespace declarations? The questions seem
important in determing how a DOM or Infoset or XOM tree or SAX stream
etc maps onto the tree-based model.)

I'm not sure what the point of section 2.1 (Modifying the Input
Document) is. Section 2 already says HTML5 defines how to get from a
document to a DOM, and says it's obvious how to get from a DOM to RDFa's
tree-based model, so the first paragraph of section 2.1 seems redundant.
As an underlying concept throughout the HTML5 spec, implementations are
free to do whatever they want as long as the output is exactly the same
as what HTML5 specifies, so it's already true that an HTML+RDFa
implementation could internally use e.g. SAX as long as the output is
equal to what's specified, so the second paragraph of 2.1 seems unnecessary.

It might still be useful to explicitly state that underlying concept,
e.g. "Note: Although HTML5 is specified in terms of a DOM, HTML+RDFa
processors are free to use any implementation approach as long as their
RDF output matches the output specified in this document." (I think
that's more general than what's in 2.1, since it doesn't talk about
details like HTML5 parser data structures - all that's important is the
input and output. Also it avoids questions about what "a data structure
equivalent to the HTML5 or XHTML5 DOM" really means (is a stream of SAX
events an equivalent data structure? (is it even a data structure?)))

"There may be a link element contained in the head element that contains
profile for the the rel attribute and http://www.w3.org/1999/xhtml/vocab 
for the href attribute." -- that's a broken definition, e.g. it doesn't
seem to allow <link rel="PROFILE" href=...> or <link rel="profile next"
href=...>. It also conflicts with section 5.2. This line should probably
just be removed, since section 5.2 is enough to allow documents to use
profile.

"The lang attribute must be processed in the same manner as the xml:lang
attribute is [...]" -- that is confusing since the xml:lang attribute
(in HTML5 text/html) is not processed in the same manner as in XHTML.
(For example, <div xml:lang="en">...</div> in text/html has no
language). It would be clearer to replace this with something like
"Where the XHTML+RDFa specification refers to the xml:lang attribute,
the language of an element must instead be determined as in the section
titled The lang and xml:lang attributes in the HTML5 specification."

"When generating literals of type XMLLiteral, the processor must ensure
that the output XMLLiteral is a namespace well-formed XML fragment." --
I don't see why this requirement needs to be explicitly specified for
HTML+RDFa, or described with such verbosity, given that XHTML+RDFa
doesn't specify it explicitly. Any processor generating RDF triples must
generate valid triples, which means XMLLiterals must have a lexical form
that is exclusive canonical XML (hence namespace well-formed etc), and
the RDFa spec does not need to repeat any of those requirements.

Given RDF's use of exclusive canonical XML, there is only a single valid
serialisation of a given input tree. So I think there's no need for
HTML+RDFa to discuss various ways of getting a value - it just needs to
define what that single valid serialisation is.

So I think the whole section could simply require:

   "When generating literals of type XMLLiteral, the lexical form of the
literal must be equal to the result of applying the [Coercing an HTML
DOM into an infoset] rules to the child nodes of the current element,
then serialising the resulting nodes to an octet stream with the
[exclusive XML canonicalization method] (with comments, with empty
InclusiveNamespaces PrefixList), then decoding the octet stream as UTF-8
into a Unicode string."

(with some non-normative explanations of the implications, and examples,
etc, but no other conformance requirements).

"Hyperlink" -- <link rel=profile> sounds more like an "External
Resource", since it augments the current document.

http://whatwg.org/html5#linkTypes defines the link-type table to be
non-normative. Is the link type table extension in HTML+RDFa meant to be
non-normative or normative? If the former, the Hyperlink/External
Resource thing needs to be specified in normative text and not just the
table.

"For documents conforming to this specification, attributes with names
that have the case insensitive prefix "xmlns:" are conforming in both
HTML5 and XHTML5." -- is it intentional that <div XMLNS:foo="..."/> in
XHTML will be conforming? Surely that markup would break any RDFa
processors, because they don't do case-insensitive attribute lookups in
XHTML, so it should not be permitted.

Also, attribute names in HTML5 are always lowercase (ignoring script
modifications etc), because the concept of "attribute name" refers to
the name in the DOM (not the bytes in the text/html syntax), and the
parser converts names to lowercase. So only lowercase attribute names
need to be made conforming.

Also, according to this, attributes like xmlns:="..." and xmlns:0="..."
will be conforming in HTML5, but authors will be confused if they use
such attributes (because they'll try to use the CURIE "0:foo" and it
will be ignored because it's invalid), so they should be non-conforming
to alert authors to their errors. Only attributes whose names match the
PrefixedAttName production from XML Namespaces should be conforming.



And some minor issues about wording etc:

"RDF in XHTML: Syntax and Processing" -- s/RDF/RDFa/ (in Abstract, and
again in History).

"The latest stable version of the editor's draft of this specification
is always available on [the W3C CVS server]. The [latest editor's
working copy] (which may contain unfinished text in the process of being
prepared) is also available." -- the first link is to an old version
(July) that looks much less stable or complete than this version; the
second link is a 404.

"By design, the possibility of [...] was squarely in the realm of
possibility." -- seems tautological; maybe remove the "the possibility of".

"heeding the minor changes in this section" -- s/section/document/ (or
specification or something).

"Section 5.5: Sequence, of the [XHTML+RDFa] specification defines [...]"
-- remove unnecessary comma.

"The HTML5 and XHTML5 DOM, or equivalent data structure, should be used
as input to the RDFa processing rules." -- s/should/must/ (I don't see
any reason why someone ought to be allowed to violate this requirement,
and still claim to be a conforming HTML+RDFa processor).

"element nesting issues in HTML documents may be corrected" --
s/may/can/ (or something similar) (use of normative RFC2119 keyword
"may" in a non-normative section seems undesirable).

"Any mechanism that generates a data structure equivalent to the HTML5
or XHTML5 DOM, such as the html5lib library" -- it seems weird for a
specification to refer to a specific implementation. The reference
doesn't even provide any information to the reader, unless they already
know the details of html5lib tree builders.

"Any mechanism [...] may be used" -- s/may/can/ (same reason as above).

"a XML mode document" -- s/a/an/

"In future versions of RDFa, the value of the profile may trigger
different processing rules in RDFa Processors." -- s/may/might/ (I don't
think that's meant to be a normative conformance requirement).

"While it is specified that HTML5 must preserve these attributes in the
DOM" -- s/must/will/ (I don't think that's meant to be a normative
conformance requirement here, and it's confusing to use RFC2119 keywords
when referring to the consequences of requirements in other specs).

--
Philip Taylor
pjt47@...

[Maciej Stachowiak]

On Sep 15, 2009, at 9:36 PM, Manu Sporny wrote:

> The 3rd draft of the HTML+RDFa specification has been released and is
> available here:
>
> http://html5.digitalbazaar.com/specs/rdfa.html
>
> The diff-marked version can be found here:
>
> http://html5.digitalbazaar.com/specs/rdfa-diff-20090906-20090915.html

I haven't yet checked if the issues I raised are resolved to my  
satisfaction (I plan to do so soon), but I think it's fine to publish  
the current draft as FPWD. I will post a CfC to do so today.

  - Maciej

>
> Changes in this version of the spec include:
>
> * Lots of xmlns: fixes and spec language changes around xmlns:.
> * Explicit references from HTML+RDFa sections to pertinent sections of
>  XHTML+RDFa spec.
> * Explicit language ensuring that RDFa attributes, attribute values,
>  and CURIEs are conforming in HTML5 and XHTML5.
> * Normative pointers to xmlns:-prefixed attribute processing that
>  should be used to create URI mappings in non-XML mode documents.
> * Added editorial warnings about potential changes in xmlns: as
>  the HTML5 document moves toward Last Call and the distributed
>  extensibility issue is addressed.
>
> There are now 2 remaining issues, 6 deferred issues (that should be
> addressed via a separate document, wiki, process), and 30 addressed
> issues. Details on the status/resolution of each issue can be found  
> here:
>
> http://rdfa.info/wiki/html5-rdfa-wd-issues
>
> There have been no issues that have been added to the wiki by  
> reviewers
> or that have been re-opened by reviewers since the last draft was
> published. Discussion related to the second draft didn't produce any
> technical issues, but that doesn't mean there aren't any. If there are
> any new technical issues, they must and will be dealt with during the
> Working Draft phase.
>
> I feel confident that the remaining 2 issues can be addressed and that
> the document is ready for FPWD.
>
> Sam, Paul, Maciej, this is a request to publish HTML+RDFa as a FPWD.
> Please let me know if there is any other W3C process that is required
> before the document can be published as a FPWD.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: The Pirate Bay and Building an Equitable Culture
> http://blog.digitalbazaar.com/2009/08/30/equitable-culture/
>

[Jonas Sicking-2]

On Tue, Sep 15, 2009 at 9:36 PM, Manu Sporny <msporny@...> wrote:

> The 3rd draft of the HTML+RDFa specification has been released and is
> available here:
>
> http://html5.digitalbazaar.com/specs/rdfa.html
>
> The diff-marked version can be found here:
>
> http://html5.digitalbazaar.com/specs/rdfa-diff-20090906-20090915.html
>
> Changes in this version of the spec include:
>
> * Lots of xmlns: fixes and spec language changes around xmlns:.
> * Explicit references from HTML+RDFa sections to pertinent sections of
>  XHTML+RDFa spec.
> * Explicit language ensuring that RDFa attributes, attribute values,
>  and CURIEs are conforming in HTML5 and XHTML5.
> * Normative pointers to xmlns:-prefixed attribute processing that
>  should be used to create URI mappings in non-XML mode documents.
> * Added editorial warnings about potential changes in xmlns: as
>  the HTML5 document moves toward Last Call and the distributed
>  extensibility issue is addressed.
>
> There are now 2 remaining issues, 6 deferred issues (that should be
> addressed via a separate document, wiki, process), and 30 addressed
> issues. Details on the status/resolution of each issue can be found here:
>
> http://rdfa.info/wiki/html5-rdfa-wd-issues
>
> There have been no issues that have been added to the wiki by reviewers
> or that have been re-opened by reviewers since the last draft was
> published. Discussion related to the second draft didn't produce any
> technical issues, but that doesn't mean there aren't any. If there are
> any new technical issues, they must and will be dealt with during the
> Working Draft phase.
>
> I feel confident that the remaining 2 issues can be addressed and that
> the document is ready for FPWD.

Hi Manu,

I'd like to officially add some concerns about the technical contents
of this draft. I realize some of them are going to be hard to
impossible to address while keeping with the goals of this draft
(which I understand to be "integrate RDFa with HTML5"), however Maciej
asked me to send this nonetheless.

The biggest concern is that I think RDFa, and by extension this draft,
is simply too complex to author documents for, as well as interpret
data from.

For example the CURIE mechanism means that there's a big risk that if
part of a document is copied, it risks loosing its meaning since
prefixes might no longer be declared. It could potentially even change
its meaning if the same prefixes are declared, but declared to a
different value, though this seems less likely to happen. The same
thing could potentially even happen if a Node is moved around in the
DOM.

Another problem is the flexibility of RDFa to express arbitrary graphs
of data. While this might not be a huge problem for someone authoring
a document since you can simply choose not to express complex graphs
someone reading a document with RDFa risks being exposed to it.

I firmly believe that one of the reasons for the success of HTML and
the web is that anyone can simply use the "view source" feature
available in most browsers, see how someone else did something, and
then do the same thing himself/herself.

It's not just the ability to create arbitrary graphs that seems
worrisome, but features like incomplete triplets, that I'm concerned
will make it hard for authors to understand other authors documents.

The complexity argument aside, I'm also not fully understanding the
processing model with regards to xmlns prefixed attributes. Is it
intended that consuming RDFa in HTML documents should be done without
looking at the namespace of attributes? I.e. that DOM Level 1 methods
should be used? I'm asking because HTML5 parsing currently requires
that attributes whose name start with "xmlns:" are parsed into the
null namespace, and with the localName containing the for example
"xmlns:foo". However in an XHTML document, parsing xmlns prefixed
attributes result in attributes in the in the
"http://www.w3.org/2000/xmlns/" namespace with a localName of for
example "foo".

While processing using DOM Level 1 methods is seems doable, it is the
only specification that I know of where that is done. I would imagine
that this will cause problems. For example a javascript implementation
couldn't use the lookupNamespacePrefix function defined in DOM Level 3
and implemented in most commonly used browsers.

Again, I realize that some of these problems might not be possible to
address, but I wanted to let you know my concerns early in the
process.

/ Jonas

[Manu Sporny]

Henri Sivonen wrote:
> Section 2 is marked as normative although its content is devoid of
> normative statements.

Your most recent issues have been added to the HTML+RDFa issues list:

http://rdfa.info/wiki/html5-rdfa-wd-issues

> I observe that four out of the six deferred issues depend on the two
> issues you left open. (I disagree with the characterization of the
> deferred issues as "implementation details".)

I'd like to setup a time that we could discuss this over the phone as I
want to make sure that I understand the issues that you see moving
forward. You've raised the XOM issue multiple times and we have yet to
see a XOM implementation of RDFa, so it is a valid concern.

In general, we could say that a parser, model or other view of the
document that doesn't allow one to retrieve namespace declarations is
not capable of implementing RDFa. If XOM falls under this class of
parsers, then it is not capable of implementing RDFa. However, I don't
know much about XOM, so I'd have to do a namespaces implementation
before I could answer your question... and that will take time. However,
even if that were done, I don't know if it answers your question. So,
when would be a good time to talk over the phone?

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Pirate Bay and Building an Equitable Culture
http://blog.digitalbazaar.com/2009/08/30/equitable-culture/

[Manu Sporny]

Julian Reschke wrote:
> Manu Sporny wrote:
>> The 3rd draft of the HTML+RDFa specification has been released
> Very interesting; I'd like to see this published as FPWD.
> ...
> Looking at these two comments it appears that head/@profile and
> link/@rel=profile really should be specified separately from RDFa...
> (this is in fact an open HTML5 issue)

Right. So, on the last telecon, I volunteered to author
@profile/rel="profile" language for the HTML5 spec:

http://www.w3.org/html/wg/tracker/actions/144

The document is due Oct. 8th.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Pirate Bay and Building an Equitable Culture
http://blog.digitalbazaar.com/2009/08/30/equitable-culture/

[Shane McCarron]

I just wanted to chime in on one aspect of your comments:

Jonas Sicking wrote:

The complexity argument aside, I'm also not fully understanding the
processing model with regards to xmlns prefixed attributes. Is it
intended that consuming RDFa in HTML documents should be done without
looking at the namespace of attributes? I.e. that DOM Level 1 methods
should be used? I'm asking because HTML5 parsing currently requires
that attributes whose name start with "xmlns:" are parsed into the
null namespace, and with the localName containing the for example
"xmlns:foo". However in an XHTML document, parsing xmlns prefixed
attributes result in attributes in the in the
"http://www.w3.org/2000/xmlns/" namespace with a localName of for
example "foo".
  

Actually... this confuses me.  According to the DOM Level 2 Core spec and the DOM Level 3 Core spec, attributes that declare XML Namespace mappings are directly manipulatable using DOM Level 1 methods [1] [2]:

"As far as the DOM is concerned, special attributes used for declaring XML namespaces are still exposed and can be manipulated just like any other attribute. "

Are you suggesting that this is not the case, and that the attributes used for declaring XML namespaces are NOT available?  As long as they are available, I should think that the act of extracting the mappings is "a simple matter of software", as my old boss used to say.

[1] http://www.w3.org/TR/DOM-Level-2-Core/core.html#Namespaces-Considerations
[2] http://www.w3.org/TR/DOM-Level-3-Core/core.html#Namespaces-Considerations

[Manu Sporny]

Hi Jonas,

Thanks for the feedback, I've noted (on the RDFa wiki) that I should go
through your e-mail in detail and pick out the issues that should be
addressed via the spec, but while ensuring compatibility with XHTML+RDFa
1.0.

I'd like to address some of the higher-level points you made and not
focus on specific spec changes in this e-mail. My goal is to not start a
perma-thread discussing RDFa's acceptable level of complexity. I'd like
to express that there are similar concerns among all of us and that many
of your core beliefs are shared among the semantic web and RDFa community.

The "technology X is too complex for authors and therefore we shouldn't
deploy it" argument is one that each standards community deals with
constantly. Rather than attempt to refute that argument, I'd like to
explain why I don't think it's an argument that has a clear "winner".

I say this as someone who has consistently argued for simplicity over
complexity when possible, both in the Microformats community and again
in the RDFa community. If there is one thing that Microformats, RDFa and
Microdata have in common, it's the desire to make the markup as simple
as possible for authors while not sacrificing use cases that are
important to each community. There are many talented people working on
this semantics problem and "acceptable complexity" is a very hard thing
to nail down when you're talking about web authors. It really boils down
to the use cases that you're attempting to solve and RDFa is attempting
to solve a much larger set of use cases than Microformats or Microdata.

Whether or not those use cases are worth solving is debatable and is
something that we have and continue to spend a great deal of time
discussing.

RDFa is more complex than Microformats and Microdata. It is more complex
because the set of use cases are more complex. Follow-your-nose,
vocabulary validation, data typing, and inferencing are just a few of
the design goals for RDFa, based on the requirements in the use cases.

It's fairly clear that RDFa is more complex than Microformats and
Microdata, and I would say that is true because it solves a larger set
of problems. What is not clear is whether it is too complex for the
majority of its adopters. No amount of discussion is going to discover
if this statement is true or not... we'll just have to wait and see. If
it is true, RDFa will fail in the marketplace. If it is not true, then
we're good.

To look at this another way, one could claim that HTML5, Javascript,
canvas, or SVG is too complex for regular web authors. Those
technologies are certainly far more complex than RDFa, yet we see
widespread use of each of those technologies on the web.

If you think RDFa is too complex, please propose an alternative or
propose alternatives to the way RDFa works that are backwards compatible
with XHTML+RDFa 1.0. We have some fairly large field deployments of RDFa
and the number is growing, not shrinking. We need to be very careful to
support these early adopters while making things simpler, if possible.

Some of these improvements that we're currently discussing will simplify
the markup a bit, but they make the implementations a bit more challenging:

* The ability to use URLs in CURIEs, which would allow people to not use
prefixes if they don't want to. For example:

<a rel="http://example.org/vocab#likes"
   href="http://example.org/dogs">Wuf</a>

The ability to create vocabulary bundles and also extend the default set
of reserved words, so authors could do the following:

<a rel="likes" href="http://example.org/dogs">Wuf</a>

Unfortunately, those changes are going to take some time to gain
consensus and traction in the community. Some of the features may never
make it into RDFa. It's clear that there will be an RDFa 1.1 and in that
we're going to unify the RDFa in XHTML and RDFa in HTML documents. So,
we do recognize that there is room for improvement and if you'd like to
help make those improvements, please do take part in the RDFa community
to make those changes.

Jonas Sicking wrote:
> For example the CURIE mechanism means that there's a big risk that if
> part of a document is copied, it risks loosing its meaning since
> prefixes might no longer be declared. It could potentially even change
> its meaning if the same prefixes are declared, but declared to a
> different value, though this seems less likely to happen.

We spent a considerable amount of time discussing cut-paste scenarios
and did as much as we could to prevent triple generation when RDFa
markup wasn't clearly specified. For example, erroneous triples are not
generated if there isn't a clear subject, predicate and object. While
this can lead to semantic data loss, it's the trade-off we made to
enable (arguably) more accurate markup.

RDFa, by design, also allows anybody to pre-load a list of known prefix
mappings in their application and create a separate graph of triples
with those known prefix mappings. So, if cut-paste resulting in
undefined prefix mappings is an issue to a certain class of user agents,
there is a mechanism that allows them to pre-define prefix mappings so
that there are less triples lost to cut-paste errors in major vocabularies.

> The same thing could potentially even happen if a Node is moved
> around in the DOM.

This is true for any technology that depends on the structure of the
HTML DOM. Microformats, Microdata and RDFa are susceptible to this
issue... but so is everything else that depends on the structure of the
HTML DOM.

> Another problem is the flexibility of RDFa to express arbitrary graphs
> of data. While this might not be a huge problem for someone authoring
> a document since you can simply choose not to express complex graphs
> someone reading a document with RDFa risks being exposed to it.

Complex markup is... complex. :)

Somebody reading the HTML5 spec source is exposed to 4MB of HTML/CSS
markup. Somebody looking at Gmail's Javascript/HTML source code, or
Facebook's page source, are exposed to a tremendous amount of
complexity. That doesn't make the technology any less useful to society,
but complexity does make it harder to understand a subset of products of
that technology.

There are trade-offs by going simpler, if there were no tradeoffs, we'd
have made those changes a long time ago. So, if there is a
simplification that you can see that doesn't result in a big tradeoff
and is backwards-compatible with most of XHTML+RDFa 1.0, we'd be glad to
go that route if it results in a simpler system.

To do that, however, we need a concrete proposal.

> It's not just the ability to create arbitrary graphs that seems
> worrisome, but features like incomplete triplets, that I'm concerned
> will make it hard for authors to understand other authors documents.

I wish I could tell you that I know whether or not RDFa is going to do
what you claim it is going to do. I don't think it will, neither does
most of the RDFa community, but we can't predict the future with that
degree of accuracy.

> While processing using DOM Level 1 methods is seems doable, it is the
> only specification that I know of where that is done. I would imagine
> that this will cause problems. For example a javascript implementation
> couldn't use the lookupNamespacePrefix function defined in DOM Level 3
> and implemented in most commonly used browsers.

Could you elaborate more on this point? Specifically, are you saying
that most Javascript implementations wouldn't be able to implement RDFa?
Or are you saying technologies that only provide DOM Level 3 wouldn't be
able to implement RDFa? Or are you saying something else?

> Again, I realize that some of these problems might not be possible to
> address, but I wanted to let you know my concerns early in the
> process.

Thank you for taking the time and posting your concerns to the list,
Jonas. Thank you, especially for doing so while keeping a sense of
decorum and mutual respect that I hope will permeate discussions around
this WD as it moves through the HTML WG process.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The Pirate Bay and Building an Equitable Culture
http://blog.digitalbazaar.com/2009/08/30/equitable-culture/

[Jonas Sicking-2]

On Fri, Sep 18, 2009 at 10:51 AM, Shane McCarron <shane@...> wrote:

> I just wanted to chime in on one aspect of your comments:
>
> Jonas Sicking wrote:
>
> The complexity argument aside, I'm also not fully understanding the
> processing model with regards to xmlns prefixed attributes. Is it
> intended that consuming RDFa in HTML documents should be done without
> looking at the namespace of attributes? I.e. that DOM Level 1 methods
> should be used? I'm asking because HTML5 parsing currently requires
> that attributes whose name start with "xmlns:" are parsed into the
> null namespace, and with the localName containing the for example
> "xmlns:foo". However in an XHTML document, parsing xmlns prefixed
> attributes result in attributes in the in the
> "http://www.w3.org/2000/xmlns/" namespace with a localName of for
> example "foo".
>
>
> Actually... this confuses me.  According to the DOM Level 2 Core spec and
> the DOM Level 3 Core spec, attributes that declare XML Namespace mappings
> are directly manipulatable using DOM Level 1 methods [1] [2]:

The problem is that the way HTML parsing works, markup like:

<div xmlns:foo="http://namespace.example.org">

Does not parse the xmlns:foo attribute into something that "declare
[an] XML Namespace mapping". Specifically, it does not create an
attribute in the "http://www.w3.org/2000/xmlns/" namespace. Or an
attribute with a "xmlns" prefix and "foo" localName. It creates an
attribute in the null namespace, with a localName that is "xmlns:foo".

So *an* attribute shows up in the DOM. Just not an attribute that
declares a XML Namespace.

Now, we can argue if that is how HTML5 should define parsing. But that
is how it currently defines it. And as far as I can see the HTML+RDFa
spec does not seem to change that.

/ Jonas

[Jonas Sicking-2]

On Fri, Sep 18, 2009 at 2:19 PM, Manu Sporny <msporny@...> wrote:
> RDFa is more complex than Microformats and Microdata. It is more complex
> because the set of use cases are more complex. Follow-your-nose,
> vocabulary validation, data typing, and inferencing are just a few of
> the design goals for RDFa, based on the requirements in the use cases.

I think this gets to the heart of the issue. I don't think that RDFa
is more complex because the people designing it didn't value
simplicity, but because it has aimed to solve more complex use cases.

> To look at this another way, one could claim that HTML5, Javascript,
> canvas, or SVG is too complex for regular web authors. Those
> technologies are certainly far more complex than RDFa, yet we see
> widespread use of each of those technologies on the web.

I *certainly* think that HTML has many aspects that are much more
complex than I would like. Much more complex than they would be if we
had the luxury of designing this thing from scratch. Just look at how
prevalent XSS and CSRF security problems are on the web and it's clear
that HTML is too complex.

Unfortunately we aren't designing HTML from scratch. We're bound by a
desire to be backwards compatible with the billions of web pages that
users are using today.

While HTML started simple, it has gotten a lot more complex over time.
For a variety of reasons.

> If you think RDFa is too complex, please propose an alternative or
> propose alternatives to the way RDFa works that are backwards compatible
> with XHTML+RDFa 1.0. We have some fairly large field deployments of RDFa
> and the number is growing, not shrinking. We need to be very careful to
> support these early adopters while making things simpler, if possible.

This is why I said that I don't think some of my comments were
possible to address. If the goal is to be compatible with XHTML+RDFa
then I don't think it's possible to reduce the complexity
meaningfully.

> There are trade-offs by going simpler, if there were no tradeoffs, we'd
> have made those changes a long time ago. So, if there is a
> simplification that you can see that doesn't result in a big tradeoff
> and is backwards-compatible with most of XHTML+RDFa 1.0, we'd be glad to
> go that route if it results in a simpler system.
>
> To do that, however, we need a concrete proposal.

I personally think that microdata is a better proposal. I do realize
that it doesn't satisfy many of your goals, but I don't share all of
those goals.

>> While processing using DOM Level 1 methods is seems doable, it is the
>> only specification that I know of where that is done. I would imagine
>> that this will cause problems. For example a javascript implementation
>> couldn't use the lookupNamespacePrefix function defined in DOM Level 3
>> and implemented in most commonly used browsers.
>
> Could you elaborate more on this point? Specifically, are you saying
> that most Javascript implementations wouldn't be able to implement RDFa?
> Or are you saying technologies that only provide DOM Level 3 wouldn't be
> able to implement RDFa? Or are you saying something else?

I'm saying that a Javascript implementation will have a harder time to
use RDFa. Or an implementation that uses any output from a conforming
HTML parser.

As stated in a previous email in the last thread, this is because markup like:

<div xmlns:foo="http://www.example.org/myNamespace">

does not create an attribute in the "http://www.w3.org/2000/xmlns/"
namespace. It creates an attribute in the null namespace (or, if i
recall correctly, the correct language is that it's not in a namespace
at all).

(For what it's worth, I think the fact that we're having this
discussion is a sign that namespace declaration is too complex).

/ Jonas

[Shane McCarron]

Jonas Sicking wrote:

> The problem is that the way HTML parsing works, markup like:
>
> <div xmlns:foo="http://namespace.example.org">
>
> Does not parse the xmlns:foo attribute into something that "declare
> [an] XML Namespace mapping". Specifically, it does not create an
> attribute in the "http://www.w3.org/2000/xmlns/" namespace. Or an
> attribute with a "xmlns" prefix and "foo" localName. It creates an
> attribute in the null namespace, with a localName that is "xmlns:foo".
>
> So *an* attribute shows up in the DOM. Just not an attribute that
> declares a XML Namespace.
>
> Now, we can argue if that is how HTML5 should define parsing. But that
> is how it currently defines it. And as far as I can see the HTML+RDFa
> spec does not seem to change that.
>  

Andy that's fine.  We don't care.  RDFa doesn't use namespaces.  RDFa
uses vocabularies and prefix mappings.  As long as an implementation can
discover the prefix mappings and transl;ate vocabulary item references
into those mappings, we are good.  As far as I can tell, that means we
are good everywhere.

--
Shane P. McCarron                          Phone: [phone] x120
Managing Director                            Fax: [phone]
ApTest Minnesota                            Inet: shane@...

[Jonas Sicking-2]

On Fri, Sep 18, 2009 at 10:52 PM, Shane McCarron <shane@...> wrote:

>
>
> Jonas Sicking wrote:
>>
>> The problem is that the way HTML parsing works, markup like:
>>
>> <div xmlns:foo="http://namespace.example.org">
>>
>> Does not parse the xmlns:foo attribute into something that "declare
>> [an] XML Namespace mapping". Specifically, it does not create an
>> attribute in the "http://www.w3.org/2000/xmlns/" namespace. Or an
>> attribute with a "xmlns" prefix and "foo" localName. It creates an
>> attribute in the null namespace, with a localName that is "xmlns:foo".
>>
>> So *an* attribute shows up in the DOM. Just not an attribute that
>> declares a XML Namespace.
>>
>> Now, we can argue if that is how HTML5 should define parsing. But that
>> is how it currently defines it. And as far as I can see the HTML+RDFa
>> spec does not seem to change that.
>>
>
> Andy that's fine.  We don't care.  RDFa doesn't use namespaces.  RDFa uses
> vocabularies and prefix mappings.  As long as an implementation can discover
> the prefix mappings and transl;ate vocabulary item references into those
> mappings, we are good.  As far as I can tell, that means we are good
> everywhere.

Actually, where is it defined how prefixes are mapped?

As far as I can see the XHTML+RDFa spec only defines how prefixes are
mapped in an XML document. I.e. how a serialized XML document is to be
processed.

Obviously, in the case of a HTML document we don't have a XML
document. So where is prefix mapping defined?

The question equally applies equally how to do prefix resolution in a DOM.

I suspect the intent is that mapping was intended to be defined
through the DOM since the spec asks for xmlns: prefixed attributed to
be preserved in the DOM. I think this is a good idea since the HTML5
spec defines how to map a HTML document to a DOM (the HTML parsing
algorithm). This would result in prefix mapping being defined for both
HTML documents and DOMs.

However as far as I can see the spec doesn't actually define how to do
prefix mapping in a DOM.

Or am I missing something?

/ Jonas

[Maciej Stachowiak]

On Sep 19, 2009, at 12:54 AM, Jonas Sicking wrote:

>
> However as far as I can see the spec doesn't actually define how to do
> prefix mapping in a DOM.
>
> Or am I missing something?

You're not missing anything. It's not currently defined. This was one  
of my points of feedback on the initial draft, which Manu believed he  
addressed by citing section 5.4 of the XHTML+RDFa spec. But that  
section does not define anything about pseudo-namespace syntax in  
HTML. It's not even the section that defines the normative processing  
requirements for CURIE prefix mappings in XML - that would be 5.5. And  
the rules in 5.5 do not even correctly describe what should be done in  
XML, as explained by be here <http://lists.w3.org/Archives/Public/public-html/2009Sep/0089.html 
 > (scroll down to Manu's mention of "Section 5.5" and my reply).

Needless to say, I am not satisfied that my comment on this has been  
addressed. It appears to me that the xmlns processing model for HTML  
remains totally undefined.

I will be reviewing the latest Editor's Draft to see if I'm satisfied  
with the resolution for other issues I raised.

Regards,
Maciej

[Ian Hickson]

On Fri, 18 Sep 2009, Manu Sporny wrote:
>
> RDFa is more complex than Microformats and Microdata. It is more complex
> because the set of use cases are more complex. Follow-your-nose,
> vocabulary validation, data typing, and inferencing are just a few of
> the design goals for RDFa, based on the requirements in the use cases.

What are these use cases? I took into account every use case that was
mentioned anywhere I could find, for microdata, and microdata handles
every one of those that RDFa handles -- the only ones I didn't solve are
also not solved by RDFa.


> It's fairly clear that RDFa is more complex than Microformats and
> Microdata, and I would say that is true because it solves a larger set
> of problems.

What problems? Could you list the concrete user problems that RDFa
addresses that make it more complex, and which microdata doesn't address?


> To look at this another way, one could claim that HTML5, Javascript,
> canvas, or SVG is too complex for regular web authors.

Yeah, they are. We've spent a huge part of the effort on HTML5 trying to
simplify as much as we could while still being compatible with the
trillion or so deployed HTML pages. If you have any suggestions for ways
we could further simplify the language, please let me know or file a bug.


> If you think RDFa is too complex, please propose an alternative or
> propose alternatives to the way RDFa works that are backwards compatible
> with XHTML+RDFa 1.0. We have some fairly large field deployments of RDFa
> and the number is growing, not shrinking.

What is your biggest deployment, in terms of volume of content processed
or number of users affected?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Henri Sivonen]

On Sep 18, 2009, at 18:40, Manu Sporny wrote:

> Henri Sivonen wrote:
>> Section 2 is marked as normative although its content is devoid of
>> normative statements.
>
> Your most recent issues have been added to the HTML+RDFa issues list:
>
> http://rdfa.info/wiki/html5-rdfa-wd-issues

Thanks.

>> I observe that four out of the six deferred issues depend on the two
>> issues you left open. (I disagree with the characterization of the
>> deferred issues as "implementation details".)
>
> I'd like to setup a time that we could discuss this over the phone  
> as I
> want to make sure that I understand the issues that you see moving
> forward.

I'll follow up on this off-list.

> You've raised the XOM issue multiple times and we have yet to
> see a XOM implementation of RDFa, so it is a valid concern.
>
> In general, we could say that a parser, model or other view of the
> document that doesn't allow one to retrieve namespace declarations is
> not capable of implementing RDFa. If XOM falls under this class of
> parsers, then it is not capable of implementing RDFa.

(XOM is a tree model--not a parser.)

Indeed, declaring a Willful Incompatibility with tree models that  
properly reflect the XML Information Set would be one way to approach  
this.

Trying to restate my concern:

Here are four propositions about RDFa that can be true or false:

1) The syntax xmlns:p="http://example.com/" defines a prefix mapping  
from 'p' to 'http://example.com/'.

2) The prefix mapping from 'p' to 'http://example.com/' is represented  
in the same way in the tree model regardless of whether the tree model  
was built by an HTML parser or by an XML parser.

3) An implementation of the HTML parsing algorithm (as defined in  
HTML5 as of 2009-09-21) can be used to build the tree model without  
modifications to the algorithm and without a tree rewriting step  
(other than optionally the Coercion to Infoset rules from HTML5)  
between the parser output and the RDFa processor input.

4) A tree model that completely, correctly and exclusively reflects  
the XML Information Set can be used as the tree model.

(For clarity: DOM Level 1 isn't a tree model that completely,  
correctly and exclusively reflects the XML Information Set.)

I want #2, #3 and #4 to be true, although I'd prefer not to have  
prefix mapping mechanism at all. Presumably, you want #1 to be true.  
More generally, I dare speculate that for each of these propositions,  
you can find people (apart from just you and me) within the HTML, RDFa  
and XML communities who want the proposition to hold true.

The problem is that all the four propositions cannot be true at the  
same time. At least one of them has to be false.

What I'm asking is that instead of leaving this inconvenient situation  
for RDFa implementors to discover as an "implementation detail" when  
they've already committed to a tree model and a parser, you make the  
choice of which one of the propositions you choose to make false and  
be very explicit about this choice in the spec. (Or, alternatively, if  
you wish to offer implementors a choice of which one to make false,  
I'm asking you to make the need for the implementor to make the choice  
very explicit in the spec.)

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/

[Julian Reschke]

Henri Sivonen wrote:
> ...
> (For clarity: DOM Level 1 isn't a tree model that completely, correctly
> and exclusively reflects the XML Information Set.)
> ...

Does DOM Level 2? I didn't think so, but it may depend on what you mean
by "completely, correctly, and exclusively".

BR, Julian

[Henri Sivonen]

On Sep 21, 2009, at 11:05, Julian Reschke wrote:

> Henri Sivonen wrote:
>> ...
>> (For clarity: DOM Level 1 isn't a tree model that completely,  
>> correctly and exclusively reflects the XML Information Set.)
>> ...
>
> Does DOM Level 2? I didn't think so, but it may depend on what you  
> mean by "completely, correctly, and exclusively".


No. I tried to contrast XOM (the most correct XML tree model that I'm  
aware of and that happens to also be an existing target model of an  
existing HTML parsing algorithm implementation) and DOM Level 1 (the  
model most preferred by the RDFa TF). I deliberately avoided  
discussing DOM Level 2 in my clarification of the issues, because DOM  
Level 2 doesn't clarify the point I'm trying to make as clearly as XOM  
even though it relates to the point I'm trying to make.

--
Henri Sivonen
hsivonen@...
http://hsivonen.iki.fi/