Groups - DITA TC Meeting Minutes 14 November 2017 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        ActionItems: 
1. Robert will fix Errata02 document to reflect Eliot's recent grammar change
2. Alan will set up a DITAWeb review for Errata02
3. Joe will write up notes on RDFa/DITA issues from meeting.


=================================================
Minutes of the OASIS DITA TC
Tuesday,  14 November 2017
Recorded by Nancy Harrison
link to agenda for this meeting:	
https://wiki.OASIS-open.org/dita/PreviousAgendas


Attendance:
Robert Anderson, Carsten Brennecke, Bill Burns, Kris Eberlein, Carlos Evia, Richard Hamilton, Nancy Harrison, Alan Hauser, Scott Hudson, Eliot Kimber, Tom Magliery, Chris Nitchie, Keith Schenglie-Roberts, Eric Sirois, Bob Thomas, Joe Pairman, Jim Tivy 



Business
========
1.  Roll call
        Regrets:  Maria Essig

2.  Approve minutes from previous business meeting:
   https://lists.oasis-open.org/archives/dita/201711/msg00009.html (Nancy Harrison, 07 November 2017 2017) 
Kris moved, 2nded by Bill, approved by TC


3.  Announcements:
       None


4. Action items
    6 September 2016
        Kris: Revise subject scheme example topic pulled from errata 01 
    4 October 2016:
        Tom: Work on aggregated minutes for 2005-2011 (IN PROGRESS) 
    25 July 2017
        Tech comm subcommittee: Consider whether to make proposal to allow steps to nest a stage 1 proposal 
    8 August 2017
        Kris: Request GitHub repo for L & T subcommittee (COMPLETED) 
    19 September 2017:
        Kris: Build errata 02 and ask OASIS to check the cover pages
        Kris and Robert: Draft response to Radu's blog post and e-mail to dita-comment 
    10 October 2017:
        Kris: propose a formal schedule for Errata 02, including TC and public review dates. (COMPLETED) 
    17 October 2017:
        Kris: Request public review for LwDITA committee note  (COMPLETED) 
    07 November 2017:
	   Robert: Work errata 02 item about @format on image (COMPLETED)
        Kris: Request public review for LwDITA committee note (COMPLETED) 


5.  Report back from Lavacon
[TC attendees were Tom, Dawn, and Keith]
- Keith, I'm still digesting it.  But overall takeaway theme from this and several other recent conferences; DITA is not being mentioned by name as much, but is being used as an underlying technology; it comes up in things like chatbots, more effective SEO, industry initiatives like IIRDS, etc.  It's sort of become the way of doing proper structured content, so businesses can do cool things on top of it. 


6.  DITA 1.3 Errata 02
        Wiki page for DITA 1.3 Errata 02
        Has the change that Eliot made in the grammar files been noted in the Errata 02 document?
- Eliot; I didn't change that, only modified the grammar files
***ActionItem; Robert will fix document to reflect Eliot's change
Proposed schedule
    https://lists.oasis-open.org/archives/dita/201711/msg00015.html (Eberlein, 14 November 2017) 
- Kris; sent schedule for publishing 
      need to freeze by end of this week, (see schedule), approve next week, review need for Alan to set up ditaweb, can you do that?
- Alan; sure
***ActionItem: Alan will set up a DITAWeb review for Errata02
Kris; we do have a week's fudge factor, also, not sure we've gotten everything worked out
- Nancy; what about 1.3/errata 01 cover page issue?
- Kris; the errata itself will contain both 1.3 and Errata 01, and the document will list changes from both errata releases, so we'll leave 1.3 as the appropriate thing to supersede.  But someone - probably me - will have to do IA work on map and build targets to make that happen. 
Motion: Kris "I move we adopt this as our schedule."
seconded by Bob, no objections, aproved by TC.


7.  DITA 2.0 stage one proposals: Discussion
        RDFa support
            https://lists.oasis-open.org/archives/dita/201710/msg00038.html (Hudson, 23 October 2017)
            https://lists.oasis-open.org/archives/dita/201710/msg00044.html (Joe Pairman, 24 October 2017)
            New e-mail
                Integrating RDFa With DITA, Metadata Improvements In General
                    https://lists.oasis-open.org/archives/dita/201711/msg00010.html (Kimber, 08 November 2017) 
Eliot; I have specific reservations, but the larger issue is that emtadata requirements are unbounded.  For people for whom RDFa are important, this proposal would be useful, but for everyone else, it wouldn't be useful and would simply make DITA even more complex.  And there are lots of things like RDFa; we're certainly not going to do all of them. OTOH, a domain that maps directly to RDFa @s is easy, we - or anyone - could do it today.  It's really about delivery; how you author content so that you have good @s is a design challange, and putting RDFa @s in the content source might not fix that.  In general, we shouldn't be adding @ domains to the core standard; maybe we should do it in a SC... 
                Metadata, DITA 2.0, and requirements gathering (Eberlein, 14 November 2017)
                https://lists.oasis-open.org/archives/dita/201711/msg00013.html 
https://lists.oasis-open.org/archives/dita/201711/msg00014.html (Joe Pairman 14 November 2017) 
- Joe; as per my previous email, I'm very cautious about just plugging RDFa into DITA, but OTOH lots of people are asking how to work with DITA and RDFa, 
- Joe; Using nested data elements makes it difficult to control values for those elements, because RDFa uses them in a different way.  The guidance isn't quite enough. What's really important is to express 'aboutness', but it's difficult if you're stuck with extra elements, or trying to work with @s, especially if you want to work with other taxonomy standards. I think metadata is a pretty core need, so we should be trying to do a bit more in the core. (see my second mail for my suggestion of a 'middle way' approach. Lastly, if we decide to go with RDFa stuff, look at a mechanism for simplfying it.
- Robert; I think as far as adding samples, RDFa examples only make sense for things that are explicitly supported in the spec; for anything else, articles or white papers would be better.
- Joe; I can agree with that.
- Robert; there are already a lot of examples in the spec.
- Kris;  are we going to engage in requirements gathering wrt metadata?  I have strong sympathy with Eliot's point; I'd rather work on core and have interested parties produce specializations outside of the core.  But I've heard enough from the TC about metadata not meeting people's needs, so how do we go about gathering requirements?   Folks at listening sessions often don't know much about DITA architecture, or the difference between DITA and DITA tools.
- Eliot; first we need to divide requirements into distinct areas:
  - architectural; eg ability to have URIs in @s
  - other; e.g., specific ways people need to encode metadata
- Joe; there's also another level, we need to distinguish the ability to have a concept model that works not just with subjectscheme, but also with external taxonomy mgmt systems.
- Eliot; that seems interesting to me too; if there's a standard around taxonomy mgmt, we should look at it.
- Chris; one potential approach is: rather than designing this into the standard, take a survey of how people include metadata, see how we can adjust the architecture to allow them to integrate with other systems.  Need to look at 'what's the current state of the art?', and 'could it be incorporated in DITA extension mechanisms?'   And if not, why not?  And can we fix them to allow it?
- Keith; if we do something for RDFA, by the time 2.0 is released, RDFa may no longer be used, or it may be very different, so we should aim for something more general in structure.  Another tack is to look at relationships between topics described by web ontology language, and look at workflow-related metadata.
- Joe; I want to make a distinction between RDFa and other metadata schemas, e.g. Dublin Core; RDF is not a schema but a way to encode relations to other schemas.
- Scott; we need to make our architecture really usable, we need to consider the practical side as well as the extensible aspect.
- Chris; I think DITA RDFa would be excellent for a SC.
- Eliot; or a metadata SC, there's plenty of stuff for them to look at.
- Kris; as a point of business, we've become much more careful about starting SCs; if we want to go that route, it might be more appropriate to have a working group instead; I'm very wary about starting new SCs.
- Eliot; I have some frustration about the general community sense that people want stuff but don't want to put resources into it, 'just have the TC do it for them'...
- Kris; I can sympathize, there's been a real reduction in corporate support for these work projects, and that could be a threat to the long-term sustainability of DITA and the TC.  So, how do we want to move forward?
- Joe; from practical side, there's an architectural block to working with metadata in DITA.  What would people like to do architecturally that they can't do now, and wrt metadata, how would that play in 2.0?
- Eliot; I agree, there's probably a small number of architectural fixes we could do to enable stuff. If you have a specific architectural issue, it would be good to bring it forward.
- Kris; can you tell us what's blocking?
- Joe; most folks want to use @s rather than elements, and they want to control them from external tools; one major issue is the lack of ability to use a URI in an @.
- Kris; I think we know from and architectural POV, there's an inability to control @ values within elements.
- Eliot; we could do stuff, but it would cross into the domain of document constraint standards; I think that if you want to constrain elements or @s, use schematron.
- Joe; but in DITA, subjectscheme is supposed to control @ values; nonetheless, you can't use an external tool to control those values.
- Eliot; but DITA shouldn't be doing that, use schematron.
- Robert; that's been one major complaint around subjectscheme; it's about taxonomy but it's not a complete taxonomy.
- Joe; subjectscheme is supposed to evaluate taxonomy, but does it?  It can't use URI's...
- Eliot; well, a key name can't be a URI, but can be expressed in another way.
maybe the answer is 'don't use SS, use something else...'  The use of DITA doesn't mandate the use of SS.
- Joe; but the standard does imply that.
- Kris; one problem was that in 1.2 SS was underspecified, we tried to fix it in 1.3, but we were constrained by backwards compatibility issues, so we're stuck with it. There are enough users of it that we can't abandon it.  
- Scott; but 2.0 is our opportunity to change things if we need to.
- Kris; but we've said we'd do our best to not be disruptive. we've already ruled out some things because of that.
- Chris; could we change it so that SS is one way to provide controlled values, but not the only way.
- Robert; you can do that today.
- Nancy; do we want to do what we did with L&T in 1.3, leave SS in, but also provide something better?
- Chris; that's a possibility. 
- Robert; I want to mention the limited number of people available to do the work on this.  Any redesign will run into the same issues that SS ran into. The intent behind SS was to do some useful things within DITA but leave deep taxonomy to real taxonomy tools.
- Joe; from my POV, SS is not awful; it can be used as a tagging aid. 
- Scott; if we don't have resources to redesign, is there a middle ground where it wil be easier to do inline metadata, since we can't today?
- Kris; what are the workarounds folks are currently using?
- Joe; some use of nested data elements, though that only works if you have a tool that hides them.  Also have some people using inline profiling @s, that gets limited, also some have profiling @ values coming from SS, and SS higher up has reference to a main taxonomy tool.
- Eliot; one quick thing would be to extend SS so you can say; 'this is my enumeration value, different from my key name'
- Joe; that's correct.
- Eliot; wrt architecture, it seems like there's a clear requirement for a companion to @props whose value allows URIs; maybe  a specialization-based @ whose value is a URI
- Chris; what about CDATA?
- Eliot; that makes it too broad; I think we need to specify a URI (or a UUID, which is why people use URIs).
- Scott; yes, adding an additional @ would be useful, since it could be used for metadata extraction.
- Joe; that would be very powerful.
- Eliot; we could probably make the same generalization mechanism as for @props.
- Robert; we'd have to work something out there, a specialized @ works in @props; but if you're defining it as a series of URIs, that makes it harder to generalize.
- Joe; the grouping mechanism would be hugely useful...
- Kris; shall we continue this on email, or maybe someone could seed it based on today's minutes, with an eye to determining where we take this, and whether there are concrete proposals to make.
- Joe; i can write up some notes, though it won't be totally objective, :-)
***ActionItem; Joe will write up notes on RDFA from meeting.



12 noon ET close 

        
-- Ms. Nancy Harrison

Document Name: DITA TC Meeting Minutes 14 November 2017

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2017-11-14 12:22:16