W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2013

Re: [HTML+RDFa 1.1] section 3.1 and 2.1

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Thu, 31 Jan 2013 15:21:03 +0100
To: public-rdfa-wg@w3.org
Message-Id: <201301311521.03540.Dr.O.Hoffmann@gmx.de>
Ivan Herman:
> Olaf,
> To be honest, I am not sure how to solve these issues, and I would welcome
> your suggestions. 

Well, at least the XHTML+RDFa variant of 'HTML5' should have the 
version attribute, I think, 'HTML5' is anyway only for tag soup processing, 
therefore not useful for documents intended to survive a long time.
The version attribute is in the XHTML namespace anyway, just because
it is not mentioned in the current HTML5 draft does not mean, that it
vanishes from the XHTML namespace.
An improvement for the syntax of the value could be to allow an URI
to something, that defines exactly, what this version means and how
to interprete the document.

Another not very practical option could be, that authors use
RDFa attributes, that reference the definition of the element in the 
related (X)HTML specification whatever version this is - this could 
implicate that all children follow this specification, if not redefined 
with another RDFa attribute value.
One can do this for all elements deviating from the defined meaning
of the parent element.
One can construct of course more advanced meta information using
RDFa on a meta element, in doubt referencing an external specification,
what a version of a format means.
If required, maybe I can write an external specification of a format
version indication - this can be referenced with RDFa to define the
meaning of an RDFa attribute referencing a  specification as a
resource or something like this ;o)

Obviously current viewers will fail to interprete this correctly, but this
is our experience with (X)HTML viewers anyway for all versions of
(X)HTML, that they do not get it completely right - therefore no surprise
for advanced authors and readers ;o)
However, in doubt everyone can analyse the source code manually
to find out the intended meaning of the document, that is independent
from the interpretation of viewers.
And the method is risky - if I or someone else decides to switch off
the server with the specification of the format version indication, 
things get undefined again - therefore better to have a more stable
internal definition.

The logical problem of this approach is of course, that one has to
interprete first the related RDFa attribute to be able to follow the
reference to the definition of the meaning of such an attribute ;o)
Typically such formal things are not a big problem for human interpreters
of such documents, therefore this is still usable as a makeshift/stopgap,
if the HTML5 working group does not manage to solve the version
indications problem (what is quite probable, because they did not
solve it in the past years, therefore effectively still one cannot
write HTML5-documents at all ;o)

A simpler approach without direct logical problems is to use
as suggested an DCMI term within a meta element referencing
applicable specifications.
But this is a solution relying on a specification out of the domain
of W3C - therefore another makeshift/stopgap for an internally
unsolved problem.
Interestingly the profile attribute seems to be removed as well
in the HTML5 draft, that is or was required to define the meaning
of meta information with DCMI - looks like another indication, 
that HTML5 is not intended for documents with relevant content,
only for tag soup ;o)

But of course, the HTML+RDFa draft adds anyway the RDFa
attributes to the HTML5 draft, why not a version attribute as well?
If it is ok to add attributes like property, content, about etc, what
is the problem with version, if it turns out, that this is essential
to get defined semantics?

Yet another option could be a generic XML mechanism
(another than DTDs) to reference the specification applicable
for the current document. Obviously it turns out, that it is
not sufficient only to indicate the namespace, one has to
add a version information as well, if there is more than one
version and different features within the namespace have
slightly different meanings in different versions (if this
appears as for (X)HTML, this may indicate anyway, that
the specificators already failed, but because nobody
is perfect, it is reasonable to care about such problems
in practice).
The mechanism could be similar to the XML (stylesheet) 
processing instruction.
This does not solve the problem for HTML5 itself, but
authors wanting to publish relevant content could simply
only use the XML-variant.

> We face two problems here. 
> In (X)HTML5 the @version attribute does not exist any more.  In previous 
> versions of RDFa we made use of that attribute and, actually, RDFa 1.1 Core
> still refers to this attribute for, eg., XHTML1.0. Processors hitting the
> @version value referring to RDFa 1.0, for example, are supposed to process
> accordingly. But, as I said, this option is not available any more in
> (X)HTML5...
> Of course, we could define a separate attribute, much like we do have a
> number of RDFa 1.1 attributes. But there comes the next issue: many
> authors, or indeed 'webmaster advices' issued by companies like Facebook,
> ignore that attribute anyway. The practice is that authors do not use it.
> Ie, we did not want to rely on the presence of such attribute to control an
> RDFa processor. Meaning that we have to define a behaviour in the absence
> of any additional hints.

One cannot define the meaning of any arbitrary tag soup as HTML5 tries to do,
there will always be some nonsense remaining.
And because there is currently no version indication method in HTML5,
every author, that follows such a draft only creates tag soup documents
without a defined meaning ;o)

I do not worry about such nonsense documents, that often disappear within
a few months or years. 
If the document has no indication, there is no urgent need for an RDFa
processor to get a detailed and correct interpretation of the content ;o)
Obviously one can say, that the tag soup is always interpreted with
the newest RDFa variant, implicating, that such documents have
no time independent meaning at all ;o)

I think, it is more important to allow authors to write documents with a 
defined meaning at all, if they want. And this implicates, that such authors 
need to indicate the version of the document format they use, else they are
not able to write something better than meaningless tag soup. 
And the probabilty, that one has an author wanting to publish documents
with a defined meaning increases, if such an author uses RDFa attributes,
indicating already some care about semantics and meaning of the content.

> So...
> On Jan 31, 2013, at 11:54 , "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de> 
> > Hello,
> >
> > the working draft
> > http://www.w3.org/TR/2012/WD-rdfa-in-html-20121213/
> > as well as this variant from today
> > http://www.w3.org/2010/02/rdfa/sources/rdfa-in-html/
> > contain in section 3.1 the sentence:
> > "Documents served as application/xhtml+xml, that don't contain a DTD, and
> > don't specify a @version attribute must be interpreted as XHTML5+RDFa 1.1
> > documents."
> >
> > Does this mean, that if for example in 20 years I write an XHTML6+RDFa
> > 2.0 document, there will be a DTD or version indication again to ensure,
> > that the document will be interpreted as XHTML6+RDFa 2.0 and not as
> > XHTML5+RDFa 1.1?
> Hopefully RDFa 2.0 would be backward compatible with RDFa 1.1, ie, it would
> not matter (although I know this is not 100% sure with RDFa 1.0/1.1 :-(.

Who knows, what the future will bring, may more or less wisdom ;o)
Already the minor differences here show, there is a need for authors
so be able to specify the version they use.

> And if this is not the case, then indeed some new attributes may have to be
> used. Actually, this issue will come up regardless of RDFa: What will
> happen with XHTML5 vs. XHTML6? Maybe some mechanism will be introduced by
> the HTML WG of the time to ensure that....

If every version has a new mechanism to indicate, to which version a document
belongs to and (X)HTML5 has none, this causes logical problems as well.
Obviously one has always to know the complete history of (X)HTML to find
out, what the document could mean - and documents without version indication
will remain without defined meaning, because those existed already before
the first draft for HTML5 was written, therefore one cannot rely on the claim,
that no indications means HTML5 - it can be any tag soup.

The indication with a DTD or an URI allows at least to discover the intentions
again, if one knows, what specification documents were available with these
identifiers. Such a mechanism is required, therefore the method with
version="XHTML+RDFa 1.1" was already suboptimal, should have been
version="http://www.w3.org/TR/2012/REC-xhtml-rdfa-20120607/" or
something related.

> > How to indicate precisely, that a document is of version XHTML5+RDFa 1.1,
> > because section 2.1 only notes:
> > "XML mode XHTML5+RDFa 1.1 documents should be labeled with the Internet
> > Media Type application/xhtml+xml as defined in section 12.3 of the HTML5
> > specification [HTML5], must not use a DOCTYPE declaration for XHTML+RDFa
> > 1.0 or XHTML+RDFa 1.1, and should not use the @version attribute."
> >
> > This does not implicate, how to indicate an XHTML5+RDFa 1.1 at all.
> > Doesn't this finally mean, that one effectively cannot write an
> > XHTML5+RDFa 1.1 document at all, because one cannot indicate, that
> > the document follows this version?
> I am not sure I follow your argument. XHTML5+RDFa 1.1 is the 'default' for
> application/xhtml+xml, unless a DTD says otherwise (ie, points at XHTML1
> and/or RDFa 1.0). Of course, if it uses a DTD, it is not XHTML5 any more,
> but it can still be XHTML1.1.

Well, XHTML+RDFa currently does not require a DTD, and if XHTML documents
had no DTD in the past, but the namespace was indicated correctly, it was
still  application/xhtml+xml without any relation to HTML5, because HTML5 did
not exist in the past. Therefore a future specification of HTML5 cannot
change the meaning of documents publish before, this would result in
nonsense. HTML5 can only suggest an interpretation for documents without
a relation to a specific version, but this does not implicate, that HTML5 can
define the meaning of such documents.
The content type only is not sufficient to provide information about the
version of the format, because there is only one content type, but many
versions of XHTML.

This is similar to interpretations of a poem - there can be many 
interpretations, but only if the author points to a document with the
intended interpretation, we can learn something about the
intended meaning. Arbitrary interpretations contain always a mixture
of the intentions of the interpreter and the work itself, what
can be interesting as well, but not necessarily to get the
intentions of the authors. The same applies, if arbitrary documents
are interpreted with the HTML5 draft - can be interesting, but
not necessarily what was intended ;o)

> Again, this is primarily an (X)HTML issue, ie, an issue of XHTML5 vs.
> XHTML1.1. RDFa just follows the XHTML5 rules here...

If we assume, that HTML5 is intended for tag soup only and 
XHTML+RDFa for semantically relevant content, this creates a
big difference.
We do not have to worry about authors only wanting to create
HTML5 tag soup.
But for XHTML+RDFa authors there is an important need to
indicate clearly, what they use, because at least some of them
care about semantics and defined meanings.
Therefore a version indication might be neglectable for HTML5,
but not for XHTML+RDFa.
And presumably if HTML5 ever will become a recommendation,
there will be authors wanting to switch from 
XHTML+RDFa 1.0/1.1 to a newer version, but without version
indication in the new variant they cannot, they stuck in a trap
and have maybe to consider to switch to a complete different
format again, because  up-to-date (X)HTML versions become  
unavailable for top quality content.

> Ivan
> > Or should one indicate the relation for example with a DCMI Term
> > (http://dublincore.org/documents/2012/06/14/dcmi-terms/)
> > like conformsTo or  format with the URI of the specification as value?
> > Is this the currently preferred approach for all types of
> > (X)HTML5-documents, because they currently have no version indication
> > itself?
> > Or is there a simpler method without the need of other formats to
> > indicate, that one has an (X)HTML5 document and not something else?
> >
> >
> > Olaf
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Thursday, 31 January 2013 14:27:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:58 UTC