> DCXMLRevision/DCXMLIssues

The following 293 words could not be found in the dictionary of 550 words (including 550 LocalSpellingWords) and are highlighted below:

Abbreviate   about   Abstract   access   additional   Adopt   all   Allow   allowing   allows   Also   alternate   and   annotation   any   appinfo   application   applications   are   as   As   associate   at   attribute   attributes   based   be   better   both   But   but   by   Can   can   capacity   challenge   change   choose   Circulate   comment   complete   Complete   complex   complexity   comprehensible   confirmed   construct   consumer   consumers   content   convenience   coomments   Core   corresponding   cost   Could   creation   creators   current   dcx   de   declarations   declare   Default   definitions   derived   described   description   descriptions   Design   discuss   disseminating   do   document   documenting   draft   Dublin   each   either   element   elements   elsewhere   embed   embedding   encode   Encoding   encoding   encodings   etc   Even   examples   Explanation   features   first   fixed   flexibility   for   format   formats   from   full   Functionality   Guidelines   handle   has   have   Have   human   if   implementers   implementing   in   include   included   incomplete   inconsistent   increases   individual   information   instance   instances   interested   is   Is   Issue   Issues   it   limitations   line   long   longer   lots   make   makes   managing   mapping   Metadata   metadata   Model   model   models   more   multiple   name   Name   names   Names   Namespace   namespace   necessary   Needs   new   no   not   Note   obtain   of   Offer   Often   Omit   on   once   only   option   or   parallel   parse   part   Path   Pattern   perceived   permissive   possible   prefer   Probably   Problem   processing   processor   Processors   processors   progress   properties   property   proposal   Proposal   proposed   providers   quite   rather   rationale   reader   readers   redefine   redundant   refer   reference   referencing   reflect   registry   Relationship   Remove   representation   representations   represented   require   required   requires   requiring   resource   response   Results   revise   Schema   schema   Schemas   schemas   Schematron   scheme   Scheme   Scope   second   service   set   shortcut   simpler   single   so   solution   Solutions   some   Some   spec   specification   specify   specs   stable   statement   still   string   subset   supports   syntax   Syntax   term   terms   than   That   that   The   the   then   Then   there   they   This   this   though   Tighter   to   transform   type   Type   Types   unambiguous   up   updated   Use   use   useful   using   Validation   validation   value   verbosity   version   ves   via   Vocab   vocabulary   was   ways   what   where   whether   which   While   whole   with   within   work   would   xs   xsi  

Clear message

Issues in the current draft

Issue 1: Functionality/Scope

Problem

The proposed format supports the whole of the "description model" described by the DCAM. Often implementers require only a subset of that model (e.g. they require the capacity to specify only a single value string as value representation in each statement). As the proposed format supports the whole of the DCAM, it supports any subset, but at the cost of some complexity/"verbosity" in the syntax which may be perceived as redundant by implementers interested only in some subset.

Solutions

Proposal

Circulate "full description model" proposal for comment in first instance.

Issue 2: URIs and XML QNames

Problem

The proposed format allows the representation of some URIs only as QNames (property URIs), some URIs either in full or as QNames (vocabulary and syntax encoding scheme URIs), and some URIs only in full (resource and value URIs). This may be perceived as inconsistent.

The capacity to encode URIs in full is required as not all URIs can be represented as QNames.

Metadata creators/providers may prefer the convenience/flexibility of using QNames for URIs, but allowing both full URI and URI-as-QName encodings increases complexity for the metadata processor/consumer.

Also limitations in processing XML QNames in XSLT 1.0.

Solutions

Proposal

Circulate current proposal for comment; revise in response to coomments if necessary.

Issue 3: Names of XML elements/attributes

Problem

Some of the XML element type names/XML attribute names are quite long. While this may make individual names more comprehensible to a human reader, it makes XML instances longer.

Solutions

Proposal

Circulate current proposal for comment; revise in response to coomments if necessary.

Issue 4: Relationship of new specification to ''Guidelines for implementing Dublin Core in XML''

Problem

The XML format described by Guidelines for implementing Dublin Core in XML was not based on the DCMI Abstract Model, but rather on a simpler model. That simpler model is not a subset of the DCAM, and there is no unambiguous mapping of that format to the DCAM.

Solutions

Proposal

Issue 5: GRDDL

Problem

DC-XML -> RDF/XML XSLT transform is still work-in-progress. Needs to be updated in line with work on DC in RDF.

Can associate transform with instance via "namespace document" rather than embedding reference in each instance. Probably better solution once XML Namespace Names confirmed/stable etc.

Solutions

* Complete XSLT transform to reflect DC in RDF spec; and set up GRDDL from "namespace document" - implementers can choose whether to refer to transform in instance.

Proposal

Note to readers that current examples incomplete. May change once specs complete/stable.

Issue 6: Validation Issues

Problem

XML Schema validation: Default content models permissive. Tighter validation requires creation of derived complexTypes. Then either

Have to do second where XML element name fixed by format. Results in lots of complexType definitions; lots of xsi:type attributes in instance. Could use xs:redefine (in schema)?

Schematron validation: XPath-based, more flexibility etc

RELAX NG: Pattern-based

Solutions

Proposal

Issue 7: Use of xs:appinfo for "term descriptions"

Problem

DC-XML applications requiring "Schema Model" information about DCMI terms have to obtain that information from elsewhere (e.g. by de-referencing the "term URI" or from a metadata registry service). Is it possible/useful to embed that information in the XML Schemas?

Solutions

Could include RDF/XML descriptions of the properties in the corresponding XML element declarations using xs:annotation/xs:appinfo? Even so, would not be included as part of PSVI, so application still has to access/parse XML Schema.

Proposal

Omit from first draft, but discuss and include if required.