Re: Practical question: elements or attributes?

On 18.4.2012 10:55, Arle Lommel wrote:
> 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.

Yes. Also please note that in HTML5 all attributes are nornalized to
lower-case upon parsing so it would be better to stick to lower-case
letters in our naming conventions, ie. no camelCase at least for HTML5
implementation. Of course we can use camelCase in pure XML version and
provide mapping eg. camelCaseEx -> camel-case-ex

   Jirka

> 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
>> ------------------------------------------------------------------
>>
> 
> 
-- 
------------------------------------------------------------------
  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
------------------------------------------------------------------