OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

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