cgmo-webcgm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: ISSUE closed: placing XCF metadata according to hierarchical structure
- From: Lofton Henderson <lofton@rockynet.com>
- To: "Galt, Stuart A" <stuart.a.galt@boeing.com>,"CGM Open WebCGM TC" <cgmo-webcgm@lists.oasis-open.org>
- Date: Tue, 21 Jun 2005 15:50:17 -0600
From Stuart's Ch.4 review:
http://lists.oasis-open.org/archives/cgmo-webcgm/200506/msg00043.html
ISSUE: Is the text contradictory between "flat" structure
of XCF and "[must] place metadata elements according to hierarchical
structure of metafile?"
RECOMMENDATION: It is a problem of wording -- clarify the wording
to remove the apparent contradiction.
DISCUSSION:
At 07:02 AM 6/8/2005 -0700, Galt, Stuart A wrote:
[...]
4.1 (last paragraph)
The
structure of the XML companion file is mostly flat.
Since it
is not the intent of the WebCGM companion file to
be a
detailed XML representation of a CGM document, there is
no need to
force the hierarchy of the CGM file to be expressed
in the XML
companion file. In fact, the WebCGM 2.0 DTD prevents
users from
doing so. However, it is mandatory to place metadata
elements
in a companion file according to the hierarchical
structure
of the CGM file.
It seemed a bit weird to me that the structure is "mostly flat"
but
must have the same heirarchy as the CGM file. Is this testable
or
enforcable in any way? Or is the user 100% responsible for
knowing
the CGM heirarchy and ensuring the XCF file is in
sync?
The user is 100% responsible for knowing the CGM hierarchy, know to which
CGM object(s) which he/she wants to bind metadata, and naming those
objects appropriately. Note that 100% knowledge of the CGM
hierarchy itself is not actually needed. E.g., if the CGM of the
below example were edited to delete the BegAps/EndAps elements (cgm
commands) whose id is "level-2-obj", leaving the contents and
descendants intact, the hierarchy would have changed above the target
"level-3-obj", but the example XCF would still work just
fine.
What the quoted text means is hinted by the final sentence of the subject
pgph, "Without a specific parent node for each metadata element, it
would not be possible for WebCGM user agents to know where, in the object
model, to insert a metadata."
So "according to the hierarchical structure" just means that,
in the XCF, each metadata occurrence (element or attribute) must be the
child of the correct parent, i.e., it must be a child of the XCF element
corresponding to the WebCGM object to which the metadata is to be
bound. Example: to attach metadata to level-3-obj in the
hierarchical model.cgm WebCGM:
BegPicBody
BegAps type="grobject" id="level-1-obj"
...
BegAps type="grobject" id="level-2-obj"
...
BegAps type="grobject"
id="level-3-obj"
...
BegAps type="grobject"
id="level-4-obj"
...
EndAps
EndAps
EndAps
EndAps
You would use the following "mostly flat" XCF, to bind the
application metadata to the proper location in the model.cgm
hierarchy:
<webcgm version="2"
xmlns:model="http://example.org/modelApplication"
filename="model.cgm">
<grobject apsid="level-3-obj"
model:partNum="bolt-100A">
<model:partLongDesc>
blah..blah..blah
blay..blah..blah
</model>
</grobject>
</webcgm>
A combination of clearer description (and maybe example) should fix
the confusion.
Regards,
-Lofton.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]