W3C home > Mailing lists > Public > public-digipub-ig@w3.org > May 2014

Comments on the Content & Markup alternatives

From: Ivan Herman <ivan@w3.org>
Date: Thu, 8 May 2014 13:45:54 +0200
Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-Id: <8C5B59C6-AADC-4F68-A987-A93BD902C98F@w3.org>
To: Tzviya Siegman <tsiegman@wiley.com>, Markus Gylling <markus.gylling@gmail.com>
Markus, Tzviya, all,

I have tried to give my assessment on the various options listed in [1]. Note that I have also added the 'Appropriateness' feature, as discussed on the call. My assessment is attached as a text file.

Cheers

Ivan

[1] https://www.w3.org/dpub/IG/wiki/StructuralSemantics#Approaches:Solution_Criteria_and_Options

----
Ivan Herman, W3C 
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
WebID: http://www.ivan-herman.net/foaf#me





@xmlns
------ 						

Native OWP: 
	yes (for XHTML)

Serialization Agnostic:
	no

Decentralized Voc. Support:
	yes

Clear AT contract:
	??

Static provisioning:
	yes

Simplicity:
	yes for end users/authors; no for script developers

Appropriateness:
	yes (in XHTML)

----------------------------------------------------------------------
@hyphen space extension  						
----------------------- 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	moderately (any value should be approved by the HTML5 WG to get the validators running)

Clear AT contract:
	??

Static provisioning:
	yes

Simplicity:
	yes

Appropriateness:
	yes (modulo the registration mechanism which gives the values the official blessing)

----------------------------------------------------------------------
RDFa/MD 						
------- 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	yes

Clear AT contract:
	??

Static provisioning:
	yes

Simplicity:
	unclear; many claim it is complicated, others disagree. MD is probably (marginally) simpler than RDFa Lite. RDFa Full is definitely more complex, but that may not be needed.

Appropriateness:
	not really. The problem is what the subject is of a specific statement. If, say, an HTML page talks about an concert, RDFa/MD is typically used to add information about the _concert_, not about the <div> element holding the concert's description. Putting another way, RDFa/MD is appropriate to add information on a chapter as a whole, on the book as a whole, ie, a possible alternative to what DC terms are used for today. But may not be appropriate for, say, the 'intrinsic glossaries' use case.

----------------------------------------------------------------------
Custom Elements (using the upcoming Web Components Spec)						
-------------------------------------------------------- 						

Native OWP:
	yes (eventually, when the specification is published in final form)

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	yes

Clear AT contract:
	At this moment probably not. ??

Static provisioning:
	Not really. A new element should be 'registered' through a simple script to be used properly, see, eg., http://www.html5rocks.com/en/tutorials/webcomponents/customelements/. That being said, the script may be very simple if the goal for the element is to be used by 'declarative' processes.

Simplicity:
	yes for end users; moderately for script developers

Appropriateness:
	yes

----------------------------------------------------------------------
@role 						
----- 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	Unclear; new values should probably be registered through a mechanism that is still to be defined by the PF Working Group (or the HTML Working Group?)

Clear AT contract:
	yes

Static provisioning:
	yes

Simplicity:
	yes

Appropriateness:
	yes, modulo the registration issue above

----------------------------------------------------------------------
@class 						
------ 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	yes

Clear AT contract:
	probably

Static provisioning:
	yes

Simplicity:
	yes

Appropriateness:
	Although the @class attribute is defined in very generic terms, ie, not only for styling, the practice is that it is mostly used for styling. As a consequence there is a major danger of value clash between styling and other purposes; as such, it is inherently error prone with very-difficult-to-find bugs. 

----------------------------------------------------------------------
@data-* 	
------- 						

Native OWP:
	yes

Serialization Agnostic:
	yes

Decentralized Voc. Support:
	yes

Clear AT contract:
	???

Static provisioning:
	yes

Simplicity:
	yes, both for end users/authors and for Javascript programmers, for whom even specific interface methods exist to handle them smoothly 

Appropriateness:
	per HTML5 specification, no.






Received on Thursday, 8 May 2014 11:46:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:19 UTC