- From: Arle Lommel <arle.lommel@gmail.com>
- Date: Wed, 18 Apr 2012 10:55:26 +0200
- To: Jirka Kosek <jirka@kosek.cz>
- Cc: David Lewis <dave.lewis@cs.tcd.ie>, Multilingual Web LT Public List <public-multilingualweb-lt@w3.org>
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