[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: DTD structure (chapter 5)
Hi all, More changes to chapter 5, I'm proposing this wording (or something similar)... --- The structure of the XML companion file is mostly flat. Since it is not the intent of the WebCGM companion file to represent a detailed XML encoding of a CGM file, there is no need to force the hierarchy of the CGM file to be expressed in the companion file. In fact, the WebCGM 2.0 DTD prevents users from doing so. However, it is manditory to use a hierarchy structure when dealing with metadata elements. Without a specific parent node for each metadata element, it would be difficult for WebCGM user agents to know where, in the object model, to insert a metadata element. See section 6.3 Relationship with XML companion file for more details. [I would then replace the extensible section with this... is it just me, or the current wording is very hard to visualise. I think that an illustration would help. Is what follows easier to understand?] The WebCGM DTD is extensible so that industry specific metadata may be added to the WebCGM object model. The extension definitions are implemented using namespaces. As an example, a part manufacturer may want to associate part information to graphical objects. This might be implemented with an extension that looks like: <!ENTITY % grobjectAttEXT "model:partNum CDATA #IMPLIED" > A host application could query the WebCGM DOM and retrieve the associated part information. --- Thoughts? -- Benoit mailto:benoit@itedo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]