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

Re: Practical question: elements or attributes?

From: Arle Lommel <arle.lommel@gmail.com>
Date: Wed, 18 Apr 2012 10:55:26 +0200
Cc: David Lewis <dave.lewis@cs.tcd.ie>, Multilingual Web LT Public List <public-multilingualweb-lt@w3.org>
Message-Id: <8B0059D3-D596-4DA9-9DE5-53FEAEAD7D1A@gmail.com>
To: Jirka Kosek <jirka@kosek.cz>
Thanks Jirka,

Sounds like I don't need to worry too much, need to accept the HTML5 ugly example, and need to specify the naming conventions in our document.

Appreciate it.

-Arle

Sic scripsit Jirka Kosek in Apr 18, 2012 ad 10:51 :

> 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:56:06 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 9 June 2013 00:24:55 UTC