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: RE: [cgmo-webcgm] ISSUE: is metadata enumeration an XCF use case?


Something that should please some of my old acquaintances among the TC ;-P

I vote 2, being I think a pragmatic approach.

Franck



-----Message d'origine-----
De : Lofton Henderson [mailto:lofton@rockynet.com]
Envoyé : jeudi 16 juin 2005 18:14
À : dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
Objet : [cgmo-webcgm] ISSUE: is metadata enumeration an XCF use case?


WebCGM TC,

We need to clarify this, so I'm queuing an issue.  Discussion?  Preferences?

ISSUE:  is full metadata enumeration a supported XCF use case?

ALTERNATIVES:

Alt.1 -- YES, full metadata enumeration is a critical use case for WebCGM 2.0.
Alt.2 -- NO, don't try to solve this use case for WebCGM 2.0.

RECOMMENDATION:  Alt.2, NO.

(If NO, should we fix the text by removing the subject use case, or by 
modifying it?  E.g., modify it to indicate that *partial* metadata 
enumeration, e.g., of 'linkuri's and 'content' APS Attrs, would be another 
possible application.  And change it to be example 3-of-3, instead of 
example 1-of-3.)

DISCUSSION:

Dieter's Ch.2 comments started a thread:
http://lists.oasis-open.org/archives/cgmo-webcgm/200506/msg00142.html

At 05:53 PM 6/2/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
[...]
>section 2.6  1.)
>Is there a normative section describing this use case?

The wording at section 2.6 #1 is:  "can be used as a scaled down XML 
representation of a WebCGM illustration by enumerating the Application 
Structures IDs, types and attributes."  Those are also exactly the words 
preceding example 4.1 in the normative XCF chapter.

Dieter further pointed out:  if we really  want to use the XCF this way we 
should probably flag the file accordingly to distinguish it from "normal" 
XCFs. We need to think about a way then to add the "name" attribute to such 
a list file. Right now we are not able to enumerate all APS IDs, types, and 
attributes: the name(s) would be missing.

A "normal" XCF is one that is designed to bind metadata to objects in the 
metafile, both standardized metadata like linkuri and private application 
metadata.  If XCF is also to be a metadata enumeration of stuff in the 
file, there are at least two issues that we don't adequately address now:

1.) the 'name' APS Attribute cannot be externalized to the XCF currently.
2.) One probably would not want to loadAndApply such a file.  (It is 
redundant with stuff already in the metafile, or if not totally redundant, 
then it's not really an enumeration.)

"WebCGM 2.0 Requirements" [1] says:
[1] http://www.cgmopen.org/technical/WebCGM_20_Requirements.html#L568

>2.6.1 Capabilities and Usage Scenarios
>
>Below is the list of use cases, identified as MUST be addressed by XML 
>content in companion files:
>
>     * Users want to maintain standard WebCGM Application Structures (APS) 
> attributes in XML files
>     * Users identify WebCGM objects either by their unique APS 'id' or 
> non-unique 'name' attribute. Hence they want to associate XML data using 
> the 'id' or 'name', whatever is important to them.
>     * Current CGM users are limited by the fact that attributes and their 
> semantics are specified in the respective profiles.

So it is not presently written down in the 2.0 requirements.  Further 
consideration of this use case could be postponed till after 2.0.  But we 
need to be sure that this is not a critical requirement for one of our user 
("cascading") communities.

At least some TC members remember the final resolution, after some 
back-and-forth starting at Cologne, that *full* metadata enumeration is NOT 
a principal use case.

Regards,
-Lofton.



This mail has originated outside your organization,
either from an external partner or the Global Internet. 
Keep this in mind if you answer this message.

This e-mail is intended only for the above addressee. It may contain
privileged information. If you are not the addressee you must not copy,
distribute, disclose or use any of the information in it. If you have
received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be
accessed by someone other than the recipient, for system management and
security reasons. This access is controlled under Regulation of
Investigatory Powers Act 2000, Lawful Business Practises.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]