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: ISSUE: must conforming XCFs be validatable?


[...oops, I goofed last time and sent it to list, instead of Ben ... no problem, I think the choices are clear enough and ready for issue discussion and resolution by the TC...]

WebCGM TC,

We resolved in 20050615 telecon that every conforming XCF must identify its version.  That raised the question of "how", and the proposal for the original issue was:  MUST contain DOCTYPE (w/ internal DTD or external ref. to DTD) and SHOULD also use 'version' attribute on <webcgm>.  This "how" issue hides a more fundamental issue:  must every conforming XCF contain DOCTYPE that defines or references its DTD, i.e., be validatable. 

The answer will mostly determine the answer to "how" every XCF identifies its version.  So we agreed that I would circulate the new issue, split out from the original issue.

ISSUE:  must every conforming XCF contain DOCTYPE that defines or references its DTD?

ALTERNATIVES:
Alt.1:  YES.
Alt.2:  NO.

Recommendation:  Alt.1, YES.

Regards,
-Lofton.

----- original issue, resolved "must identify version" -----

At 04:40 PM 6/9/2005 -0600, Lofton Henderson wrote:
Source:  Editors.

ISSUE:  must every XCF instance identify its version?

In ch.4, the examples 4.1, 4.2, 4.3 show <webcgm> tags without 'version' attributes.  The examples also start and end with the <webcgm> and </webcgm> tags  (except 4.2 with a piece of internal DTD subset defining an extension element, which btw looks to me like wrong syntax.)  The examples do not show the XML declaration, and do not show a DOCTYPE (which presumably would contain an external reference to the WebCGM XCF DTD.)  [Side suggestion:  make the examples be complete xml files.]

In 4.2, the DTD defines:  version CDATA #fixed 2.0

So if the XCF instance contained a DOCTYPE referencing the DTD, the version would be defined.  (#fixed means:  if 'version' is present, it must be 2.0; if not present, 2.0 is the default).

If an XCF instance contains neither a DOCTYPE nor 'version' attribute on <webcgm>, then its version is unknown.

Question.  Is WebCGM 2.0 going to allow such un-versioned XCF instances to be conformant?

Alt.1:  no, fix the current ch.4 text.
Alt.2:  yes

RECOMMENDATION:  Alt.1, no -- every conforming XCF must somehow identify its version.

If Alt.1 is accepted, then "how"?  There are several ways to achieve it, here's one proposal...

PROPOSAL.  1.) Require that every conforming XCF must contain a DOCTYPE referencing its DTD (and may also have internal DTD subset for extensions, of course).  And, 2.) Recommend that the 'version' attribute be used on the root element (<webcgm>).  I know that #2 is redundant with #1, but there are circumstances and scenarios where it is convenient to have the information there in the XCF instance, instead of in some remote referenced resource (the DTD).

Regards,
-Lofton.


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