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: ISSUE: is metadata enumeration an XCF use case?


I second Alt.2, No

Postpone until 2.1. It's an interesting use case, but it would require
a new path in the DTD and XCF work, which up to now has only been
dealing with "loadAndApply" scenarios.

Regards,
Dieter

> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com]
> Sent: Thursday, June 16, 2005 6:14 PM
> To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
> Subject: 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.
>
>
>



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