[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] Question about WebCGM DTD
DF> Benoît, DF> I think the "limitation" was coming from a vendor point of DF> view: for simplification of parsing and WebCGM elements DF> interpretation. Did Dieter or myself ask for this? I honestly don't remember. DF> For instance in your sample, once you find anything else than a DF> linkuri you can stop interpretation of any other elements. I'm not doing this in my implementation. And if I have to do that, you're asking me to write more code. DF> As a user I would say that the "limitation" is acceptable but DF> removing it could facilitate transltation for viewing from other DF> DTDs. I agree with you that having this restriction in place imposes unnecessary restrictions on deriving profiles. They can impose that restriction if they wish to do so, but I don't think WebCGM should impose it. DF> Yet, I would prefer the way that ensure quality and availability DF> of implementations. I can only speak for Itedo's implementation, but this restriction has little impact on quality and availability. I actually think it's easier to implement without the restriction since it's one less 'rule' to look for. I would be nice to hear from others on this matter. -- Benoit mailto:benoit@itedo.com DF> Regards, DF> Franck DULUC DF> Technical Data Research Manager DF> Customer Services - SDND DF> AIRBUS France DF> Phone: +33 (0)5 61 18 19 16 DF> Fax: +33 (0)5 61 93 59 44 DF> mailto:franck.duluc@airbus.com DF> Address: DF> BP D0611, 316, route de Bayonne DF> 31060 TOULOUSE Cedex, FRANCE DF> -----Message d'origine----- DF> De : Benoit Bezaire [mailto:benoit@itedo.com] DF> Envoyé : mercredi 23 février 2005 20:27 DF> À : CGM Open WebCGM TC DF> Objet : [cgmo-webcgm] Question about WebCGM DTD DF> The chapter 5 from the Munich meeting is marked with the following DF> comments from Franck and Dave: "Globally, it seems to me that we should DF> have some wording/links to justify the content model of our elements. DF> Clarify why the extensions to the content model occur at the end of DF> the individual content for each element". DF> I originally had a hard time understanding what needed to be clarified? DF> After looking at the DTD in more detail, I think I now understand. DF> Let's look at 'grobject', its content is currently defined as: DF> <!ENTITY % grobjectEXT "" > DF> <!ELEMENT grobject ( linkuri* %grobjectEXT; )> DF> Hence the comments, but to the best of my knowledge, that's an error, DF> it should be: DF> <!ENTITY % grobjectEXT "" > DF> <!ELEMENT grobject ( linkuri %grobjectEXT; )* > DF> Do people remember ever taking the decision that extended elements DF> must be the last child of its parent element in the XML companion DF> file. DF> To me, this should be valid: DF> <grobject apsId="myId"/> DF> <linkuri .../> DF> <ben:myElem .../> DF> <ben:anotherElem .../> DF> <linkuri .../> DF> </grobject> DF> If I correct the DTD, is a justification for our content model still DF> required?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]