W3C home > Mailing lists > Public > public-change@w3.org > June 2015

RE: Advancing the GCT Proposal

From: Owen Ambur <Owen.Ambur@verizon.net>
Date: Mon, 22 Jun 2015 00:04:49 -0400
To: <public-change@w3.org>
Message-id: <000b01d0aca0$990d12a0$cb2737e0$@verizon.net>
Dennis, see my responses to your questions below in [brackets].

Owen Ambur
Chair, AIIM StratML Committee
Co-Chair Emeritus, xml.gov CoP
Webmaster, FIRM

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Tuesday, June 16, 2015 5:26 PM
To: public-change@w3.org
Subject: RE: Advancing the GCT Proposal

Well, Toto, we are not in Kansas anymore.

I have no idea what this is all about and I hope that it is not intended to
be a meaningful conversation on the CTMarkup list.

The only thing I see in this particular screed is a claim that
change-tracking and XML documents that are change-tracked be subject to
domain semantics.  

In terms of something actionable, I am not certain what the recommendation
is.  Could it be one of,

 1. A generic mechanism is useless?

[I don't believe a generic mechanism would be useless.  However, I
personally am more interested in seeing reality made of guidance like that
issued in Executive Order 13642 by President Obama, making
machine-readability the avowed *default* for government information.
http://xml.fido.gov/stratml/carmel/EOOMRDwStyle.xml]

[I recognize that others have different opinions and believe that CSV, JSON,
and non-standard XML may be "good enough for government work," but I believe
an unrecognized implication of the President's guidance is that XML schemas
(XSDs) should be specified for all Federal records series, including, for
example, Executive Orders.
http://www.archives.gov/research/start/how-records-grouped.html  Indeed, I
take the failure to specify such XSDs as yet another case of bureaucratic
double-speak compounded by the hubris of feeling empowered to direct others
to "do as I say, not as I do."]

[It seems to me the President's directive sets forth good practice not only
for agencies at all levels of government, worldwide, but also all
organizations whose documents should be matters of public record.]

[Again, I recognize that others may have other opinions, but my opinion is
not exactly new.  It is closely related to the two proposals I made that
prompted the Federal CIO Council to charter the xml.gov CoP in 2000 --
http://xml.fido.gov/documents/completed/genesis.htm -- and to ask me to
chair the group for the last six years of my career.]  

 2. A generic mechanisms is useless without an accommodation of domain
considerations?

[My sense is that you doth protest too much.  I haven't heard anyone suggest
that generic capabilities would be useless ... just that they fall short of
what is to be desired.  If such capabilities are the best that can be
provided now, I'd say full speed ahead.  Often it is impossible to move to
higher levels of maturity without first passing through the lower levels.]

 3. Domain considerations must be dealt with from the get-go? 

[No, not necessarily, but it would be nice.  Plus I suspect that
authoring/editing tools that are designed from the ground-up to deal with
valid XML instance documents may have the capability to track changes in
them anyway.  So to the degree that may be the case, the only question is
whether the documentation of such changes can be freely and accurately
shared across XML authoring/editing tools.  Toward that end, an XML change
tracking standard capable of dealing with valid XML instance documents would
be nice to have.]

 4. There is some domain of interest that folks have a shared interest in
seeing served?

[Again, I can't speak for anyone else, but I personally am intensely
interested in tools, apps, and services supporting the StratML standard (ISO
17469-1), whose vision is:  "A worldwide web of intentions, stakeholders,
and results."  If others do not share my interest in that vision, no harm,
no foul.]

[However, if they are willing to share their intentions with me, whatever
their intentions may be, I'll be happy to render them in StratML format for
inclusion in our collection at
http://xml.fido.gov/stratml/drybridge/index.htm#Other  Indeed, I'd love to
see the goals and objectives of all of the W3C's groups, as well as other
SDOs, rendered in open, standard, machine-readable StratML format ... so the
rest of us could understand what they are trying to accomplish... a novel
concept, don't you think ... sharing objectives more efficiently, in
machine-readable format, with others who may wish to help accomplish them?
http://xml.fido.gov/stratml/drybridge/index.htm#W3C]

I think looking at a generic mechanism that accomplishes what it
accomplishes is fine.  

[If anyone disagrees with you on that point, I don't care to hear from them
... because I don't disagree with you.]

To the extent that one needs to know an application domain to correctly
change an XML document (with or without tracked changes), GCT is not enough.


[Perhaps you are correct, but I will be surprised if the leading XML
authoring/editing tools are incapable of keeping track of changes to valid
XML instance documents.]

That's like saying programming language grammars are not context free, yet
providing context-free grammars for them, along with separately stated
semantic conditions/constraints is of great value.  I think one approach is
to view GCT the same way -- as a context-free treatment that is always
valid, but the semantic constraints that limited it beyond syntactic matters
have to be known to have produced it properly.

[I'm not sure I completely understand your point here.  However, again, I'll
be surprised if the leading XML authoring/editing applications are incapable
of tracking changes to XML instance documents that validate against schemas
like those for the StratML standard, and I personally am not particularly
interested in "generic" (non-valid/non-machine-readable) documentation.  I'd
like to think we might be close to the point of being able to move beyond
such documentation to higher levels of maturity.]

 - Dennis

[deleted]
Received on Monday, 22 June 2015 04:05:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:11:23 UTC