W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > April 2012

Re: Practical question: elements or attributes?

From: Jirka Kosek <jirka@kosek.cz>
Date: Wed, 18 Apr 2012 10:51:40 +0200
Message-ID: <4F8E809C.3040409@kosek.cz>
To: Arle Lommel <arle.lommel@gmail.com>
CC: David Lewis <dave.lewis@cs.tcd.ie>, Multilingual Web LT Public List <public-multilingualweb-lt@w3.org>
On 18.4.2012 10:30, Arle Lommel wrote:

> Some of the data categories are rather complex (take processTrigger
> for example) and have rules about some components being mandatory and
> some being optional. I've not done this with a schema before, and
> perhaps it can be done, but how do we parse and enforce data
> structures when we no longer have a unique element to enforce those
> structures on (since the data categories are now elements that can
> apply to many kinds of elements)? I.e., if we have 20 constructs that
> can apply to a span, each with their own data model, how do we modify
> the data model for span itself to support validating all of these
> different data models? Does the new version of XML Schema address
> ways to enforce co-occurrence restrictions for attributes of an
> element (e.g., if you have foo as an attribute you must also have
> bar, but you can have bar without having foo)?

Hi, RELAX NG supports this (and W3C XML Schema 1.1 as well) and we need
RELAX NG implementation in order to plug out schema into existing
validator.nu or validator.w3.org.

> Since we will need to support multiple data categories on elements,
> and we would rename using the nested convention outlined above, does
> that mean that something like the following would be considered
> valid?

Probably yes.

> I do realize we are intending all this primarily for machine
> processing, not human readability, but I really wish there were some
> better way to handle this kind of situation that allowed for easier
> selection of the relevant attributes for any given task. If we are
> using attributes I don't think we can avoid it, especially as our
> goal is to not mess up the structures of the documents things get
> applied to, so we cannot add extra divs to separate the kinds of
> data, but I don't find that sort of thing very satisfying…

Well, HTML5 extensibility is not satisfying we probably can't come with
something much better.

  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member

Received on Wednesday, 18 April 2012 08:52:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:43 UTC